Yep, you can use the HSERIAL version for DIY, Phoenix use the RTS version as for higher speeds, although soon maybe change this one to hserial+rts (may make the code look cleaner) and inputs can come in while it is calculating the next setting, so should minimize overhead… I have the rover now converted to HSERIAL version and it is talking better but I have a few bugs in my calculating the speed to send to motors…
Yep, that makes sense. I still have the robonova still collecting dust (actually it is in a box but have not had any interest in doing anything with it yet. Now if I could adapt the 18 servos to make a Phoenix with it…). And yes Winter does have it’s advantages.
Sounds great! The HSERIAL version for DIY is that the file called “diy transmitter xbee.bas” the only file found in the “DIY remote” directory (last update 3. november)?
Oh, another Q: How did you power the XBEE explorer regulated board? Using regulated 5v from BB2 or directly from the 6v battery? The board says 5v but reading the information on Sparkfun web page it has 16v max input. I guess it would be ok to connect it to the 6v battery then.
-eh wait, you didn’t use the explorer board on the DIY, but you used it on one of the robots and thats the same I think…
I thought I would update the zip file a little bit. Please note: All of the normal disclamers. There are several funciton in this code that have never been tested, (Actually I edited these functions out of the file to make it compile faster).
But I am liking my Rover better working with the HSERIAL implementation. The bright side is that other than a simple define in the file to say:
XBEEONHSERIAL con 1
There was no changes to the source code, at least the rover file. Obviously there are several changes to the support file.
There are several projects in this zip file under the robots directory. Some that you may find interesting.
XBeeConfigure - This project/program uses the S_IN/S_OUT to ask questions, like what is the current baud rate (list provided). It then queries the xbee for the: My value (The identifier) and a description (NI - Node Identifier). It then asks you if You would like to change them and if so it allows you to type in a new hex MY value and a text string for the identifier. It then asks for new baud rate. There is a different default for using RTS(57600) and HSerial (62500). After you choose the one you want it will update the XBEE.
DIY Transmitter - This is my current one using the RTS line and standard helper functions. The older version using HSERIAL version is up in different directory.
Phoenix_V21K - My version of the Phoenix code modified currently for CHR-3 and XBEE running RTS (currently)
XBeeRover - Rover with Arm code modified for XBEE. Currently using HSERIAL updates and working better. Need to check my motors out to see why one wheel motor not working… Also arm control usage needs tweeking. Not sure about controling arm with Left joystick without detent… But one can start playing with it.
XBEEBrat - currently RTS - not working well - will soon convert back to HSERIAL.
I’m afraid I have total ignorance when it comes to wireless devices. If you ever go to Spark fun’s web page under “wireless” there are tons of different types of boards that communicate wirelessly. Between bluetooth and XBEE, I assume XBEE is faster? There are so many different types out there now I don’t know what’s what. Which is easier to use? XBEE or the Blue dongle like in the Lynxmotion tutorial?
Just to have one thing a bit more clear for what command switch is what. They are refered as W,X,Z,Y and ESC,Enter,Down,Up in the code (diy transmitter xbee.bas). I hope I got it right to say that ESC = W = CmdBtns.bit0 = in4, Enter = X = CmdBtns.bit1 = in5, Down = Z = CmdBtns.bit2 = in6 and so on for the Up cmd. Ok?
Finaly, I’ve my DIY remote up and running with both XBEE and the RC DM8 module!
I did get some trouble with configuration of the XBEE’s, but thanks to great help from Kurt it was an easy fix. Using the XBEE configuration program (written by Kurt) is the safest way to do it. My problem was that I changed the baud to a non-standard manualy (using X-CTU terminal) without changing the ATGT to 3 right away.
Anyway, the DIY with XBEE seem communicate fine with Phoenix (so far).
I did also add 4 command switches to the DIY like Kurt did. I also added a switch for selecting between XBEE and RC DM8 module. The DIY program needs to be updated when shifting from one module to another, but I just like having the two options available. Becide that I added two power connectors so that I can use the DIY while charging the battery.
Pictures of the DIY remote:
Another picture showing the extra switches and the new power connectors (btw, I added a diode for avoiding reverse voltage):
Your updates look great. I have a new pass at converting the phoenix over to the HSERIAL version, which have its advantages. You might want to try this out to see if it makes the connection between xbees more stable. To make this work the code will change to the 62500 baud rate so the configure program needs to be rerun. First do the read at the 57600, then do the write at 62500.
I try to disable the HSERIAL from receiving stuff without losing anything, before I output to the SSC-32, but the XBEE if it is in the process of reading could still receive up to 2 more characters which could corrupt the the serial going out to the ssc-32. If you try this out and you get some twitches, I was thinking about adding a pause 1 in the servo driver.
The begging of this code looks like:
[code]ServoDriver:
; kurt was here
;Kurt was here #ifdef cXBEE_RTS
gosub XbeeRTSAllowInput[0] ; no - bugbug - should abstract this away …
; also chance that there could be a couple of characters that are received after this
; so maybe should pause 1 to allow this to happen… #endif
fSSCPinChange = 0 ; initialize to say no pins have changed
; Defer any timer overflow interrupts as we only interrupt 30+ times per second. so
; we should not lose any during the time it takes to output the SSC command.
disable TIMERAINT ;disable timer interrupt
;Update Right Legs
for LegIndex = 0 to 2
gosub ServoOutputPin[cCoxaPin(LegIndex) ,(-CoxaAngle1(LegIndex) +900)*1000/1059+650]
[/code]
I was thinking of adding the wait as the comment specified. But have not tried that out yet.
Wow, this was just awesome! 8)
I’ve played with Phoenix for about 20 minuttes of walking, rotation and some long periods of just standing for checking the timeout issue. The communication part seem to work pretty flawless right now!
FYI I changed LJOYUD to RJOYUD when calculating the InputTimeDelay in the phoenix_control file. We don’t want to change the speed when moving the body up/down .
Also set the HalfLiftHeigth = 1 in the Ripple Gait 12 steps gait, I don’t know why Jeroen had temporarily commented this out to “0”.
The joystick calibration part on the DIY bugs me a bit, do you have any idea of what that could be?
I didn’t need to add the pause you mentioned.
Great work Kurt!
That is great to hear . I will look at the joystick stuff this morning (I hope). Maybe once everything is working I will pair down some of the code to remove some of the ifdefs in the XBEE as the HSERIAL version appears to work better on all of the robots!
It would be useful if the actual joystick and slider values showed on the LCD display while doing the joystick calibration also. And then maybe a menu option or something where you could check out the stored max/min values afterwards? Using the UP/DOWn cmd buttons.
I understand, but for now I think I have a quick and dirty solution which is easy to do and I think works better than before. This is I simply constrain the generated value to 255 before it trys to store it in a byte variable. It already previously constrained th minimum to make sure it did not go negative… so in the main part of the program after the label start:
You have lines that look like:
bPacket(2) = (((((sums(0) + SumOffsets(0)) min (AToDMins(0)*8)) / 8) - AToDMins(0)) * 256) / AToDRanges(0)
Change them to look like:
bPacket(2) = ((((((sums(0) + SumOffsets(0)) min (AToDMins(0)*8)) / 8) - AToDMins(0)) * 256) / AToDRanges(0)) max 255
IE just add a set of parentheses and the max 255. Then for my use I then reran the joystick ranges, with simply moving straight up and down and left to right, without trying to get the absolute maxs and mins that are at some diagnal location and then saved them away. Then when I move I have most of the range and no wrap around. Some of the range is not available as the center locations on my joysticks may not be exactly at the mid point. Could try to have the code compensate by maybe having the code fudge the range to be a bit larger than it it is and then constrain it… Let me know if you think we need this.
Kurt
Edit: I updated the zip file with the changes to both versions of the transmitter with this change.
That easy fix sure helped avoiding the byte overflow. It seems like I got full byte range on all joysticks also now.
I’ve been experimenting with high speed walking on my two favorite gaits: the smooth 12 step ripple and 8 step tripod. The cycletime are down to 39 mS (including XBEE when holding the same joystick position) and the servodriver are around 33mS, that sure helps for the speed! 8) That gives a minimum SSCTIME to around 75mS.
I’m really looking forward to see what we can’t get from the ARC32…
EDIT: It smells like I’m pushing some other limits too… Yesterday one of the tibia servo broke down, today one of the femur servos. It was one of the H-bridge that gave the magic smoke. I’ve been using these servos since 2007. Oh I hate that smell…
As an experimental version, I udated my support file, such that when it requests data from the transmitter, it does not wait around for it to be received, but continues to use the old data until the data has been sent back from the transmitter. That way your robot can continue to walk and chew gum while waiting for the serial and wireless delays. I just posted the one changed file in case someone wants to try it out and see what it does to the response.
Kurt
P.S - Zenta - I would love to see how you changed the way the controls are used on the phoenix!
I’ve just done some testing with you new “xbee_taserial_support.bas” file.
It seem to work very fine when it comes to how much time the Controlinput sub occupies from one cycle. Around 2,2 - 3 mS all the time! 8) Thats very much better than reading RC channels!
I’m wondering, I know you did some changes to the ServoDriver sub. I measured the time using the logic analyser, the ServoDriver always took about 33 - 34 mS when walking. A screenshoot from the analyser:
I’m using this code for sending the pulses to the analyzer:
[code]
DebugPin1 con 4 'test pin for timing tests
DebugPin2 con 5
;snip…
high DebugPin2
;Read input
GOSUB ControlInput
;GOSUB ReadButtons ;I/O used by the remote
low DebugPin2
;snip…
high DebugPin1
GOSUB ServoDriver
low DebugPin1 [/code]
But when doing bodyrotation something strange happends. Sometimes the ServoDriver sub take alot shorter time, about half the time:
The robot seem to work ok though. Does it have something to do with the interrupt that are enabled and disabled in the middle of the ServoDriver? I’m puzzled…
I attached the session from the logic analyser if you are interested. XBee timing.zip (21.5 KB)
Sounds good, tomorrow I will look into the startup sequence tomorrow. My guess is that when I am timing out, I am not resending some message… Should be easy once I figure it out
In my version of the servo driver, that uses my own version of serial output to get up to full speed, I put in code that says, if the requested value for a servo is the same as the previous version, then there is no need to waste time sending this out over the serial port. So for example if you are doing some movement with just one leg, the time taken in the servo driver gets a lot shorter…
I see you are having fun with your logic analyzer. Sure has saved me several times.
Lets hope so, I believe it should be a relative easy fix (for you though… )
Ah! That explains it then! Very smart solution Kurt. The only thing that I’m wondering about is that when doing continous body rotation all servos should get a new position all the time.
Yeah, its a very useful tool. When I saw you posted some result from the analyser I knew that I just had to get one. Before I got the logic analyser I used an oscilloscope, it worked but it was much harder to get the result I wanted.
.
. I will look at the joystick stuff this morning (I hope). Maybe once everything is working I will pair down some of the code to remove some of the ifdefs in the XBEE as the HSERIAL version appears to work better on all of the robots!
