Hi All,
Great! “Binary only” it will be 
I just added the new set of gaits Zenta gave me and I just have to say something about it…
God I LOVE the sound the Triple Tripod makes! When the T-Hex walks on my wooden floor it sounds like galloping horse is running by! Great work Zenta!
Have to go, need to gallop some more…
Xan
Thanks, glad you liked it!
Yeah, I’ve to admit the triple part make a cool sound.
Video???
LOL, how about a sound recording? 
Maybe this weekend…
I’ve got a a few questions:
I decided to use the constants to allow a single point of configuration for all servos. Removing the calculation and make is fixed to 10 like you described a few posts before doesn’t seems right. Now it can be adjusted when we use other servos with different a PWM / deg value. I think that leaving out the calculation doesn’t give us much of a performance win to. Are you fine with this?
Reading the voltage of an analog pin is pretty easy. This little test program reads the input of AX1, VL (input 17)
BattVoltage var word
main:
adin 17, BattVoltage ; Battery voltage
BattVoltage = (BattVoltage*1955)/1000
serout s_out, i38400, [dec BattVoltage,13]
pause 1000
goto main
I’m surprised that the value isn’t absolutely stable. I added a voltage of 6.04V using a net adapter. The readout was between 6.03V and 6.15V which makes a difference of 0.12V. Do you know what the working voltage and turnoff voltage of your lipo is? (I always reload the lipo of only 1 of the 2 red leds on the UBEC are on)
If it is accurate enough I will implement it. Otherwise we could also use an array and calculate the average of a few reads. But this adds more overhead…
Xan
Hi Xan,
As you know I’ve just answered this in our last chat.
Keeping the constants for pwm calcs is the best way.
As soon as the LiPo voltage reaches a predefined level the LiPo safety gets triggered so that you won’t be able to run the robot any more. Thats the most important part. I’m using 6v as a trigger level on my PolyQuest LiPo’s. Using about 6,3v would be even safer for all brands.
Hi all,
Small update:
Only 2 more to go…
Xan
Sounds great! Let me know if you have a version you wish for someone else to try out 
Kurt
Hi Kurt,
I’ll make sure I’ve got an alfa version by the end of this evening.
Xan
Hi Xan,
Was thinking of a new work item(s).
1a) I have had a few occasions when a leg would act funny or jerk a little randomly, and found that if the timer interrupt happened while doing serouts to the SSC it could corrupt the output, especially at faster baud rates. So my versions have a set of disable/enable Timer interrupts that bracket the serouts to SSC. (I set which interrupt I am using as a constant as it changes for Bap28 versus Bap40/Arc32). With Timer A you only have about 7 or 8 interrupts per second, so won’t lose interrupt during the serout code.
1b) Some input controllers like XBEE may use interrupts (directly or indirectly through hardware serial port). So I also added call outs to the Control code that said, disable your interrupts now/ It is OK for you to Enable them again.
Added: On some robots, that I use the pS2, I also have an XBEE on P14-P15 so I need to move the PS2 to another set of pins. At least half the time on Bap28 and Lynxmotion PS2 remotes the internal pull-up resistor on the Basic Atom Pro is sufficient for the Dat line. This works for P0 and P16, which on the Bot Board 2 is the only reasonable locations to start a group of 4 pins… (P4 does not work as P6 and P7 have lower voltage and did not work. P8 does not work as P9 is used by the speaker… But if needed could probably use the pull-up on that pin as well…
So in my PS2 code I start the InitController like:
[code];[InitController] Initialize the PS2 controller
InitController:
#if PS2DAT = 0
PUCR5.bit0 = 1 ; Note these pull-ups may not be sufficient for all PS2 remotes.
#endif
#if PS2DAT = 16
PUCR1.bit1 = 0x1 ; 16 is on H8 P11 which has a pull-up
#endif
high PS2CLK
…[/code]
Added Maybe? Recent Zentas (with a little help) enhancements to running GP Player. Again XBee code needs to disable interrupts during the issuing of commands and query back from the SSC-32. (Also needed a slight pause). But in addition to this there were call backs added to this code to the controller code such that the it could give additional feedback to the user. Also it allowed the controller to update the running of the sequence.
Along this same line, my versions have some places where the main code may tell the control code about some events, which allows the code to inform the user or the like. My additions may not have been generic enough in that it said XBee Play a sound… But this could be updated to be something like: ControlEventCallBack[EVENT]: Where we could define a set of events like (low power shut down …)
That’s all for now!
Kurt
Hi Kurt,
Thanks for the feedback! Some of the points are new to me so you need to fill me in a little bit. I would be happy to discuss them with you.
Does the rather slower TimerA has an high enough resolution to sync both BAP and SSC? I think it is a good thing to reduce the amount of interrupts. Can you provide me an adjusted version of the alpha release with this new timer?
I’ve seen the enables/disables but I wan’t really sure what they where doing there. So I commented them out. I will uncomment them.
Isn’t it a better solution to disable/enable ALL interrupts when going in to critical sections like updating the SSC? This way we don’t need to add code in the “core” file which is only used when the bot is controlled by XBEE.
I think you’re a one of a kind guy, having 2 remotes on one bot! 
No serious. Most of the time I use my DIY remote while programming / testing. Once the software is ready I simply swap receivers and try the PS2 remote. This should be good for debugging / testing but I doubt this has any value for most of the users. But please, let me know if I’m on the wrong track here
Isn’t it possible to have the feedback from the bot to the remote defined in the XBEE file? The idea sounds very interesting. Having a predefined set of events that can be used to transfer information from one part of the code to the other. I’m totally in to this but I think it’s a good idea to split this idea into a new topic and work this further out. In the mean while we should get our TA base version (v2.1) ready. I think the event stuff should be added later on since we still need to test the idea…
Thanks for the input and let me know what you think!
Xan
Hi Xan,
Quick first answer will get into more later:
1a) TimerA - with division 8192 gives us a resolution of .512ms, which for any of our code I think is accurate enough. Will give you updated code.
1b) On XBee we do not disable interrupts, that would cause data loss, what I do instead is to change the RTS line coming from the XBee to say don’t send me any more data. I could imagine other controllers like Bluetooth or serial or the like might need the same…
Not sure, how many out there may have other uses for their hardware serial port… But I agree it is probably a minority of us. But for example I have in the past used the HSEROUT to talk to serial LCD display…
Two parts - The current GPPlayer code is self contained, you start it and never get a chance to interact, until it completes. So if we want this functionality we will need some callback or the code reconfigured such that it calls ControlInput and ControlInput checks state or… May not be able to report anything with PS2, but could maybe allow user to manipulate the sequence…
Other feedbacks may be able to be deduced by ControlInput. Like you shutdown the robot due to low power. Might be variables that can be used or the like. Not sure about others, like with TA type code, where this code will live and what feedback can be or should be given back to the user… We will see as we go.
Thanks Xan,
Kurt
Hi Kurt,
Thanks for your answers!
The resolution is more then enough. The less interrupts the better. Thanks for this good update!
Clear! I’ll return the “shut up!” command
If it it ok by you, we will leave it for now…
In the current way the GP player works we did not had to read the control inputs since we couldn’t interact with the GP player. But with the upgrade Zenta did it is getting a big change anyway. I will wait unit you’ve got it tested.
Thanks!!
Xan
Hi Xan,
Quick question for you. Is it possible to use this code on an arc-32? I am thinking it should run with little modification since the arc-32 is BAP based but I wanted to ask to be sure. I do have an ssc32 as well, so really the arc would just replace the botboard and to start I would still use the ssc32 for servo sequencing.
I just want to know if I can get it working like that so I can play around with it and learn… then maybe migrate the ssc32 functions to the arc32 at some later time.
Thanks in advance.
Yes, the code can run on an Arc32…
If you look at the Beta version 2.1 thread: viewtopic.php?f=8&t=7658 you will find code for the Arc32 without an SSC-32. To help keep things cleaner and remove some #ifdef type code, we removed the Arc32 (with SSC-32) or Bap40 support from the code. It is not hard to add back in. In fact my local machine has such file…
This file replaces the file by the same name in the different zip files I uploaded on the thread I mentioned above…
Kurt
Phoenix_Driver_SSC32.bas (11.6 KB)
Ahh, okay, I was counting on having to do that myself, but this is better. Thanks. I was more worried about something like the clock speed differences causing a problem, but I guess not. Thanks for the help.
Yep, the different processor does make a difference. In that on the Bap28 it uses TimerA of the underlying H8 processor, but on the Arc32 (or Bap40), it does not have TimerA. It was replaced with TimerB1. The main place that depends on the speed differences is the timing code and there are different multiply/divide constants to convert the ticks into milliseconds…
Kurt
Ahh, got it. This is even better, now I can experiment with and without the SSC-32. Thanks a bunch!
Okay, sorry, another question. I just got my Phoenix walking (And am VERY impressed!) but I have not calibrated it yet, and I can tell it definitely needs it. I just can’t figure out how to do that.
I am looking in the config file and see a comment saying “First calibrate the servos in the 0 deg position using the SSC-32 reg offsets, then:” but I’m not sure what that means? I’ve already searched things like “Phoenix calibrate” but I didn’t see anything explaining that. Would someone be able to point me in the right direction?
edit: Oh, I should mention, I’m using an ARC-32.
Hi,
Check out this: lynxmotion.net/viewtopic.php?f=8&t=6042&p=74384&hilit=+ARC+terminal+offset#p74384
Ahh, ok, perfect. Thanks.
