DIY Remote Control XBee controller for Robotics

linuxguy · October 18, 2009, 9:26pm

I just got two of the Series 2.5 2mW XBee modules. Once I got them talking, I didn’t need to do anything else since they are now just a wireless serial cable replacement. I’ve got one set up to be a Coordinator, and the other is setup to be a Router/End Device. I don’t yet know if they will work if I reset the Coordinator to be a Router/End Device, so will have to check into that. The Pro XBees shouldn’t need any more special setup than the regular modules, but we will have to find out for sure.

I have an idea for my own wireless robot controller using XBees.

8-Dale

robotdude · October 19, 2009, 2:52pm

We depleted all of Hitecs spare Laser 4 joystick assemblies. They sent me a couple with parts missing for the stick. We just added the rubber pieces to get one more DIY radio assembled. We used to install them onto our in house radios to ease the wear on the thumbs. lol

rotorman · October 21, 2009, 1:08pm

Hi All,

Forgot to mention I was off to the Himalayas for a month (really). Nepal is surprisingly warm this time of year…but no robots…

I had some pretty basic code working at 9600 before i left, but its not very clever compared to kurte’s and was just based on simple timed shots. Well done to kurte and all for the continued work.

The sparkfun carrier boards work just fine for those still thinking about it.

I ordered the parts for a display for my controller so will integrate that into the hardware. I dont like small displays so went for a OSD-232+ text overlay driver board by Intuitive Curcuits LLC (icircuits.com/store/index.html) running on a standard 7" TFT LCD automotive-type headrest screen. Entire setup about $150US. Havent fired it up yet, but if it is as good as i think it is, it will rock. Lets me overlay text and graphics on my video feed from the bot.

Will post some pics soon for those interested.

robotdude · October 21, 2009, 1:53pm

Sounds incredible. You might want to start your own thread for the project. I’m sure many will have lots of questions about it. Thanks for sharing!

zenta · October 23, 2009, 3:41pm

Hi Kurt,

I’ve got all my new robot parts now
I ended up ordering the XBEE’s from Trossen. They was pretty easy to setup with X-CTU for setting baud, CH, DL, MY and ID.

But I’m wondering, did you try the XBEE together with Xan’s v1.3 code? Or does the hserial mess up things. I’ve little exp with this part (interupts and communication). I’m just hoping to get a XBEE solution for my hexapods.

oh… I’ve to get my kids to bed… I’ll try to study you code more before asking more Q’s.

Thanks.

kurte · October 23, 2009, 4:30pm

Hi Zenta,

I have not tried it yet with Xans code, but it is on my TODO list. However my first attempt may be with the Bap40 as I currently have it connected that way.

Yes HSERIAL can cause problems with other serial output functions, like serout. I wrote a timer assisted serout function that appears to work pretty well, but you can only pass it a buffer to output as I don’t know how to integrate in all of the variable parameter lists. That function is currently in the transmitter file I posted up on this thread. I will need to verify that the TimerVs on both the 28 and 40 are compatible and need to factor in that the 40 is 25% faster… Such a problem

Likewise on the BAP40 there are two hardware serial ports, HSERIAL2 is on the same pins as HSERIAL is on BAP28 and HSERIAL on the 40 is on SIN/SOUT. So I could maybe make a simple cable to plug the serial port of the BAP into the SSC-32… But I will try other approaches first!

On my Bap40 version I modified the timer code to make sure that we do not output a new command to the SSC-32 until the previous command had a chance to complete, such that it no longer needed interrupts. That is you can use timerA with clock/8192 with overflow bit for 9th bit, which if I calculated properly is a little over 1/4th of a second, which I believe is plenty for the code we are timing.

Kurt

kurte · October 29, 2009, 4:35pm

It is hard to decide if to post here or on my other active thread Bap28 to Bap40, but …

As I mentioned in the other thread, I have Xans 1.3 code compiling for both Bap28 and Bap40 for either PS2 or XBee: viewtopic.php?f=4&t=5542&start=22

As I ran into some issues with the Bap40 and HSERIN, I decided to try out the Bap28 on my Hex with XBee control. So far it looks like my hex code is working on the XBEE. I don’t have all of the fancy stuff merged in from the PS2 code yet, like the stuff when you are holding the L1 or L2 button down, but I have it walking, rotating, one slider selecting the body height, selecting gaits and balance mode.

The code for this is up on the other thread. I don’t think I have made any real changes to it since then. The code is using my own timer assisted serout functions to talk to the SSC-32, as we were concerned at serout being corrupted by the HSERIAL interrupt processing. Appears to work great at 38400 and works reasonably well at the 115200 baud rate although I notice a leg twitching from time to time, so I may need to do some tweaking.

I also have the E key on the remote go into the only send data when it changes mode which appears to work as well. It has the code in it to use the timer such that if the robot does not receive a notification of anything new in about a second it does a query anyway to make sure the remote is still there.

Will play more with this over the next few days, integrating the rest of the PS2 code into the XBee code, maybe playing with bidirectional stuff, like maybe pressing the “B” button on the remote, will display the battery level(s) on the robot on the DIY remotes display…

Kurt

km6vv · October 29, 2009, 7:36pm

Good progress Kurt! I’m going to have to get busy and get your Phoenix example running on my hexapod!

Alan KM6VV

zenta · October 30, 2009, 9:18am

We just have to follow them both then! And thats fine for me.

Sounds very promising! I hope you’ll get rid of the twitching.

For all users of LiPo batteries that would be very useful! In addition there should be a sort of alarm on both the robot and DIY when the voltage are close to critical. A flashing screen on the DIY + alarm

kurte · November 4, 2009, 6:08am

I have been doing some more playing around with the code and integrating it into newer version of phoenix code. Also having some fun.

I now have most of the functionality Integrated in to the phoenix (actually CHR-3) and it is working reasonably well, but it still needs some tweaking.

Today I played some more with the bidirectional communications. I added in the support of having the robot send strings back to the remote to be displayed. So now when I press the A key on the Remote, it ends up displaying “Walking” On the second line, likewise when you press the B key it displays “Body Translate”, like when you press some of the other keys it Displays the newly selected Gate name on the Remote. For example when you press the “1” key it displays “Ripple 6”, likewise the “2” key displays “Ripple 12” … Tomorrow I may display which leg is being manipulated…

Over the next day or so, will work on smoothing over my integration on the Hex and then migrate all of the changes back over to my Brats. Also will work on the timer version of serout. May have it buffer up the outputs instead of having the interrupt code and main code so in lock step with each other. May may generate a Timer Serin… Then I will try kicking up the SSC-32 again to full speed.

That is all for now

robotdude · November 4, 2009, 2:32pm

Gulp! Whoa!

Very nice!

Let me know what changes to the faceplate you would like. I will make you a new one. Good job!

kurte · November 4, 2009, 4:29pm

I know most won’t find this interesting but I thought I would mention a few things that bit me yesterday coding wise yesterday, in case it might help out others not run into the same problems that I did.

I wanted a quick and dirty function that would simply take a pointer to the string to pass back to the DIY receiver. For most of these I make the strings using BYTETABLES. Also to make it easy to modify the strings later and not forget to update the count of bytes, I decided to put the byte count at the beginning of the string instead of a second parameter. So for example when I wanted to pass the “Walking” to the other side the code looked like:

_WALKMODE bytetable 7, "Walking" ... gosub ControlOutputString@_WALKMODE]

The control function grabbed the first byte from the pointer as the count and then incremented the pointer and then processed the string, by computing a checksum and sending the packet to the DIY.

Well next I wanted to do the different gaits. So first I defined the strings like above, but then I had an index number in the range 0-7

The strings looked like:

_GATENAME0 bytetable 8, "Ripple 6" _GATENAME1 bytetable 9, "Ripple 12" _GATENAME2 bytetable 12, "Quadripple 9" _GATENAME3 bytetable 8, "Tripod 4" _GATENAME4 bytetable 8, "Tripod 6" _GATENAME5 bytetable 8, "Tripod 8" _GATENAME6 bytetable 7, "Wave 12" _GATENAME7 bytetable 7, "Wave 18"
I could have coded it with a bunch of if Gaittype= 0 then … Output _GateName0, but I don’t like that code. So next I tried to create some type of pointer table.
I was trying to do something like:

_GATENAMES POINTERTABLE @_GATENAME0, @_GATENAME1...
But Pointertable is not defined. I also tried LONGTABLE, but it complained about the @ was not a constant, although the generated address should be. I might be able to setup the table in assembly. May play with this later. Also I will ask Nathan (AcidTech) about this.

So I tried a different approach. That is set the pointer to the address of the first string, and then walk my way down the strings until I get the address of the one I want. That is if I want the address of the _GATENAME1, I grabbed the first byte that pointer is pointing to which was the count, then I added the count + 1 to the pointer and that should get me to the next string (I thought). It did not work so I converted to assembly language, which still does not work. After debugging this, I found out that, the above BYTETABLE entries does not generate the same bytes as:

Again excuse this boring post
Kurt

km6vv · November 4, 2009, 6:47pm

There’s your problem, BASIC!

Although I’ve ran into byte/word alignment problems in C as well. No

#Pragma align (0) ?

Glad you got it figured out.

Alan KM6VV

eddieb · November 4, 2009, 8:41pm

Does it always add a 0 to the end or just sometimes? Is it possible it is just using a ASCIIZ format to represent the strings (like C does)?

eddieb · November 4, 2009, 8:42pm

Ah speaking of which, are you doing both ends (controller and robot) in BASIC?

kurte · November 4, 2009, 9:20pm

Yep, most of the code is basic, but I also slip in some assembly language functions or code from time to time.
For example the function I mentioned above currently looks like:

[code]pString var pointer
ControlOutputString[pString]:
; BUGBUG:: Will not work for zero count, but what the heck.
; First we need to get the count a compute the checksum - for the heck of it will use assembly…
mov.l @PSTRING:16, er0 ; get the pointer value into ero
mov.b @er0+, r1l ; Get the count into R1l - start of the checksum
mov.l er0, @PSTRING:16 ; Update pointer value to be after the count byte.
mov.b r1l, r1h ; save away into r1h to use as counter
mov.b r1h, @B:16 ; save away to pass to hserout…
_COS_CHKSUM_LOOP:
mov.b @er0+, r2l ; get the next character
add.b r2l, r1l ; add on to r0l for checksum
dec.b r1h ; decrement our counter
bne _COS_CHKSUM_LOOP:8 ; not done yet.
mov.b r1l, @BCHKSUMIN:16 ; save away for basic to use

#ifdef BAP40
hserout2 [XBEE_RECV_DISP_VAL, bChkSumIn, 0, b, str @pString\b] ; Send data to remote (CmdType, ChkSum, Packet Number, CB extra data)
#else
hserout [XBEE_RECV_DISP_VAL, bChkSumIn, 0, b, str @pString\b] ; Send Data to remot (CmdType, ChkSum, Packet Number, CB extra data)
#endif

return
[/code]
As I said I could do this all in basic but when I was not getting the results I expected I did the simply assembly language code.

And it only puts the zero on some of the time, like when the number of elements in the byte array are an odd number.

Kurt

kurte · November 10, 2009, 12:29am

Just a quick update again…

Over the last several days, I have been working on making the DIY Xbee and making it work with Xans version 2.0 phoenix code. Hard to know which thread to post this information. Since my current implementation of the XBEE code is using HSERIAL which has been known to impact normal bit-bang serial output functions especially at higher speeds, I have worked some on my timer based serial output functions. Actually I have now written 3 different versions of it… I won’t bore everyone with the details. Also since I know that Xans code does inputs from the SSC-32, I wrote a timer based version of serin.

With a simple test setup with just a ABB (yep old one) with an SSC-32, I was able to issue a VER command at 115200 and get the proper results back. I am still worried about some interference from interrupts, but will continue to play with this. So today I integrated these changes with the phoenix 2.0 code. I had to change everywhere that uses serout cSSC_OUT and cSSC_IN to use these functions. Note these functions are pretty simple in that they only take a pointer to a buffer and a count, so all conversions have to happen external to them. So I now have my CHR-3 walking with this code. Still need to play more with the CHR-3 configuration and the appropriate scaling of the different controls, but it moves, can select different gaits…

But, I was still having some jitters. So I have currently tried a couple of different approaches that may both help.

The XBEE can be controlled by hardware flow control (RTS). I tried this earlier using it with SERIN, but there is a problem, in that the XBEE does not immediately stop when the RTS line goes back high and may send maybe 2 more characters which were being lost. But I have tried hacking up my own control to still use HSERIN, but when I am about to do all of the serial outputs to the SSC-32 I set the RTS line HIGH to say don’t send anything now… It may help. My appbee sip board brings this IO out with voltage level shifting. The Sparkfun version does not bring it out by default, but there is a solder jumper on the board to tie it to DIO3 which is brought out. However it has not been voltage level shifted, but we can probably use P6 or P7 on the BAP which appears to output a lower voltage.
Since I had a little helper function to output the new value for a pin to the SSC-32, I simply keep a table of 32 values and if the value for that pin does not change, I don’t output it again to the SSC-32. This helped remove most of the twitch and may also improve performance…

It would be interesting to try out these changes on a phoenix or other hex that is not using the DIY XBee code to see how well it works and if you can run reliably run it at I115200 and what it does to the performance.

Let me know if anyone is interested.
Kurt

kurte · November 10, 2009, 9:16pm

In case anyone with the DIY wish to try the Xbee stuff, here are the current files.

I also included a copy of my timer test program with two versions of the serouts…

Kurt
test taserout.bas (28.6 KB)

zenta · November 11, 2009, 3:47pm

Thanks for sharing your work Kurt! 8)

Hopefully I’ll try this out in the near future.
I’ve not downloaded the files yet, but did you also explain how to contect the XBEE boards (pin connection)?

kurte · November 13, 2009, 9:27pm

Thanks Zenta,

Sorry, so far I have not written any full instructions, but hopefully soon, it is not hard to wire it in.

I now have a version that no longer uses HSERIAL as to remove the interrupts from the system. Long story short, I had to modify my own version of timer based serial input to support flow control. This is because the XBEE sends usually 2 extra bytes after the flow control says to stop. My version buffers these characters up. Tried some other variations, but this appears to work well at my current baud rate of 62500 which is a standard HSERIAL baud rate but not a standard anything else. So I may change the XBEES back to a more standard baud rate of 57600, but will also need to update the DIY software as well. The other bright side is that I don’t have to ifdef differently for BAP28 and BAP40 (HSERIN vs HSERIN2).

Currently using the selmaware XBEE adapter as it had all of the needed IOS brought out. Will now modify one of my Sparkfun and simply solder in an jumper wire from the CTS line to an appropriate female pin to plug into the BB2. As this does not have any voltage conversion hardware will plug into either P6 or P7 on the BAP as these pins appear to only ouput 2.5-3V which should work fine.

As you know I have a version of phoenix_v20.bas that outputs to the SSC-32 at full speed 115200 which had some jitters. I think I have that fixed now by disabling timer interrupts while outputing the SSC-32. Should not be a problem as we only get this interrupt maybe 30 times per second and Disable/Enable around the two for loops that output to 3 legs each. I would think this should speed things up as the serout is maybe 3 times faster, plus with the code I sent you, you only output it to those servos which actually change, so in many cases this may only be a smaller subset…

If anyone wish to see these versions, let me know.

Kurt