DIY Remote Control XBee controller for Robotics

Lynxmotion Electronics & Software
1

Here is a place holder picture, until things are back in one piece: :laughing:
http://i416.photobucket.com/albums/pp245/Kurts_Robots/State-if-disarray.jpg

As I mentioned in the thread on my new Brat, I am now in the process of converting my DIY Remote control to be XBee baised instead of Spektrum DM8 radio. You can see some of the different XBee holders that I have in the other thread: lynxmotion.net/viewtopic.php?t=5403

As I now have the hardware talking to each other, I am now working the code conversion of the DIY remote as well as a sample receiver program that I will then merge into one (or more) of my robots. As I start the code conversion some interesting options come up, which so far include:

  1. I need to develope some form of handshake between the two units. I could keep blasting out the current info and have the receiver try to figure out where a new frame of information starts (seems primitive). Could Work closer to PS2 code, where Robot sends a request and waits for Controller to send current data. Next option would be for Controller to know if data has changed and send out a simple pulse saying I have something new. The Robot when it receives this and desires the new data can then query it when it is ready. This should cut down traffic a lot. Could enhance this to by setting thresholds on how much the data needs to change before the change signal is generated…

  2. What form of data should be sent. Lots of possibilities, but the main ideas are: Leave it in RC servo format 1500 center (Does not make a lot of sense here). Convert it to be very similar to PS2 packet. 1 byte for each slider/direction of stick with 128 as zero, and 2 bytes for the state of the buttons. This would work well, but I believe we found that these joysticks maybe had a range of 392-692 (~300 values), so converting to 1 byte would lose some accuracy. Could instead send 2 bytes per slider/joystick (SWORD). More accuracy but longer transmit/receive time. Might be a good tradeoff if you need this. Optionally the code could be setup to send either. Buttons would be encoded as 2 bytes, with 1 bit for each button.

  3. Should we reserve one (or more) of the buttons on the keypad for stuff on the remote. For example you may want to press a button and have it display the different robots, you have configured your remote to control and allow you choose which one… Could add another button for this but currently I have only 1 (2 if I don’t use RTS) or maybe 3 if I use some hardware hack on P9 which I believe Xan has done.

  4. What to display on the LCD. Could keep like now which shows the values, which is great for debugging, but may not be that interesting in other cases. Could hard code several pages that you can cycle through and/or could have pages or fields that the current robot could upload. Things like distance to object, or how many things have I fired, or I just fell down…

  5. I need to work on latency time. The current code is geared around the cycle time of the RC transmitter. May want to reorg such that I am always ready to transmit when the remote robot want’s it…

That is most of the questions I am thinking about right now. Suggestions?

The XBee conversion is going a little slower than it should as I keep running into diversions. (You can easily skip the rest of this paragraph!)The first diversion was that the AppBee Sip board from Selmaware which takes care of the 3.3v to 5.0V signal conditioning for RX and TX also does it for RTS, which their examples in their manual use. This allows the XBEE to hardware buffer up any transmissions and only output them to the serial port when the RTS line is brought low using the SERIN TX\RTS form of serin, which Atom Pros support. So I tried this and received nothing. … AcidTech (Nathan) found the problem and build a new version which now works! :smiley: The question will be to use or not use this later as the Sparkfun adapter which is cheaper and smaller may not condition this signal. But may be able to reorder pins and use of the two IO lines that normally are 3.3 volts on the BAP… The second diversion is I unfortionatly wired up the cable to the second one wrong and had +5 and Ground swapped, may have hurt the board, luckilly had a third one. :blush:

Kurt

2

Item 2 (PS2 emulation) with a little 3 mixed in sounds pretty good.

We will always have issues with the A to D on the joysticks because of the inability to scale the output of the joystick before the A to D gets it.

Items of interest back from the robot would be battery voltage(s), robot status (standing, at rest, fallen over, etc.), temp, sensor status, etc.

3

Quick update:

I made some progress, I am currently using HSERIAL to do the XBEE on both ends. Ran into minor linker problems with using serin with RTS line.

The transmitter program has been reworked to send out packets that look at lot like PS2 packets, with the bytes ordered:
0 - Checksum of the other bytes
1 - Buttons High
2 - Buttons Low
3 - Right Joystick L/R
4 - Right Joystick U/D
5 - Left Joystick L/R
6 - Left Joystick U/D
7 - Right Slider
8 - Left Slider

I currently have the handshake where I simply send 1 byte from the robot to the controller saying I want it and the controller sends the data.

While working on the transmitter to convert values of Joysticks I found that my joysticks did not all have the same ranges and were different than the values that Robot Dude had on his, so I put code in to scale it depending on the range of each one… Will later add a calibrate function to allow user to move all joysticks and slidders around to find actual values…

I have a test receiver program that loops receiving the packets and dumping the information to S_OUT. I dump the buttons in binary. I should reverse the bytes to make it easier to show low bit to high… I then dump the slider values in decimal. They appear to be Talking reasonably well, as you can see from this simple output:

1:B1 0000000000000000 127 127 128 51 0 0 
1:B3 0000000000000000 127 127 129 52 0 0 
1:AF 0000000000000000 127 127 128 49 0 0 
1:91 0000000000000000 127 127 128 19 0 0 
1:FF 0000000010000000 127 127 128 1 0 0 
1:7F 0000000000000000 127 127 128 1 0 0 
1:BF 0000000001000000 127 127 128 1 0 0 
1:7F 0000000000000000 127 127 128 1 0 0 
1:9F 0000000000100000 127 127 128 1 0 0 
1:7F 0000000000000000 127 127 128 1 0 0 
1:81 0000001000000000 127 127 128 1 0 0 
1:82 0000001000000000 128 127 128 1 0 0 
1:7D 0000000000000000 127 125 128 1 0 0 
1:78 0000000000000000 127 120 128 1 0 0 
1:69 0000000000000000 127 105 128 1 0 0 
1:59 0000000000000000 127 89 128 1 0 0 
1:49 0000000000000000 128 72 128 1 0 0 
1:35 0000000000000000 128 52 128 1 0 0 
1:1E 0000000000000000 128 29 128 1 0 0 
1:A 0000000000000000 128 9 128 1 0 0 
1:3 0000000000000000 128 2 128 1 0 0

Next things I would like to do include:

  1. Tell XBees to go to higher speeds currently 9600 - Also want to experiment with only sending when data changes
  2. Take Test program and build receiver into robot
  3. Experiment more with XBEE, currently using address 0 and 1 on default channel and PAN, would like to experiment with this.
  4. Expand on 3, have remote be able to querry the XBEE space and see which robots can be controlled and then configure it and robot.
  5. Have different pages of info per robot, where data is uploaded real time…

That is all for now
Kurt

4

Great progress Kurt!

You sure save many of us for much time by doing this research. At first I was a bit (just a little bit though :wink: ) worried about only using 8 bit resolution for the joysticks. But I think the linearity and response time are more important than higher resolution. Hopefully that will work just fine.

If I remeber correctly there was a little problem using HSERIAL in Xan’s code? Something about conflict in the interrupts? Well I’m not sure though…

Anyway, I wish you good time with this work and your work are highly appreciated! Thanks for posting.

5

Thanks Zenta,

I may in the end allow each robot to decide what resolution it wants. For example if the prompt from the robot is a: 1 send 8 bit resolution, and if it is a 2: send 16 bit resolution, Or if we don’t mind a little extra computer processing, could send 10 bit values. But this may be a waste on my remote, except maybe for the sliders.

My Mins and Maxs Analog to Digital values for the joysticks were:

Left Joystick: LR 361-598 (238)
UD 426-638 (213)
Right Joystick: LR 392-636 (245)
UD 416-630 (215)

So 8 bit was perfectly fine. But the Sliders had a value from 0-1023, so I am throwing resolution away here… If you want to check out your own controllers range, you could run the simple test program:

[code]i var word
advals var word(6)
advalsPrev var word(6)
AdPortTbl bytetable 0, 1, 2, 3, 18, 19
fChanged var bit
start:
fChanged = 0
for i = 0 to 5
adValsPrev(i) = adVals(i)
adin AdPortTbl(i), adVals(i)
if ABS(adVals(i) - adValsPrev(i)) > 1 then
fChanged = 1
endif

next

if fChanged then
	for i = 0 to 5
		serout s_out, i9600, [dec adVals(i), " "]
	next
	serout s_out, i9600, [13]
endif

pause 100
goto start[/code]

Kurt

6

Thanks for posting the test program, I might try it out.
The main reason for the limited range of values from the joysticks must be that the joysticks dosen’t use the whole range of a potmeter. And the sliders use the whole range (approx. 0 - 5v).

So the conclusion is that the easiest way is to use only 8 bit after all. I’m pretty sure I’ll get similar result as your. Converting the 10 bit slider readings into 8 bit shouldn’t be a big problem either.

7

Hi Kurt,

Great work on the XBEE stuff. I’m really interested in this since XBEE will open a lot of new possibilities like bidirectional communication. (and maybe speed up the transmission?) And it’s a bit cheaper to have a XBEE module on every bot. Having a RC receiver on every bot is pretty exp…

Are you planning on replacing the RC module or are you planning on having both of them in the same remote? This would be totally great. Don’t know if it is possible though. Free pins and space are very limited now.

I’m in for a bit of both options. I think the bot side should have the option to query the status of the remote at all time. It would be great if the remote gives a signal if something is changed. This will limit the data and battery use. Would something like this be possible?

Maybe you could make two different query commands. Like give me all data (when the bot (re)starts) and one like give all changed data. This would also cut down the traffic. Although there is a possibility the bot can miss some data…

I think that sending bytes like you decided to do is better then sending data in servo format. So I totally agree with your decision.

I’m using the rotary / push button to control / setup stuff on my radio. I’m using it to scroll though different kind of information which allows me to view other stuff like the battery voltage.

Although I’ve started out using P9 I’m not using that pin at the moment. I totally reswapped the pin layout so I should see what I pins I’m really using. But having the push button on P9 gave me a buzzing sound. So combined that signal with one of the 4 outputs used for the keyboard. This works great. Let me know if you need more information on this. I should make some documentation and post it on the forum somewhere for others to uses as well.

This is simple, add the same push / rotary button as I did :wink:

Interrupts used by the HSERIAL command will mess up other timed stuff. It messes up “normalâ€

8

Thanks Xan,

Yes I am having fun with the XBee stuff. I am first trying to get the basics to work well and then expand on it. I have some of the handshaking working pretty good, but keep flushing out little things that I run into with the new BM Studio.

My current approach is to replace the RC transmitter. As you mention we don’t have the IO pins left to do both. Yes it should be a lot cheaper to simply add an Xbee module to the different robots instead of the RC receivers. As you mention it also opens up more types of communication between the remote and the robot. This includes sending back data to display. In addition to this, it allows me to try other things, like maybe have a VB application on the PC, that either the remote or robot can send data to as well. All you need to do is to simply change the destination ID and send the data…

So far I have the code setup that the Robot simply asks for the whole data: I have the prompt in the form of a simple packet:

So far I only have command: 1 with no extra data…

Once I have this working reasonably well, I will integrate it into my PS2 brat code. This should not be difficult at all as the data returned is almost identical to PS2 packet:

<buttons 1><buttons 2>

Yes: I plan to have another packet that says Give me data if it changed or the like. Not sure yet on how to initiate the handshake yet, but will try soon.

One of the next things I want to work on with this experimenting is to how to pair robots/remotes. That is, it is easy for me to simply say my remote has XBEE id of 0 and my Robot has an ID of 1 (as I currently do), but get two of us in the same room, that won’t work. I can simply choose a random PAN id, plus different IDs which may work, Or I can setup a TextName that I query for. But I think I will have some mode that can do a scan and once the user chooses a robot, it will save the 64 bit address away in the Baps EEPROM on the remote. Maybe save up to 4 or 6 of them…

I thought of putting in a rotary button like yours, but did not find one. Also yours takes I think 3 IO pins which is hard to get… It would be interesting to see your current stuff, maybe should post more details under the other DIY thread.

So far I have not made any hardware modifications to the DIY, except to pull out the RC receiver and right now have a larger XBee board sortof tapped over the hole. I did however finally drill a hole into the top side of the case and mount an RS232 plug and soldered a small extension cable that plugs into the bot board, so it makes it easy to reprogram the remote.

I was thinking about adding 3-4 small switches to the remote, one near both joysticks and maybe one near the display (optional). The idea was to make it easy to hit the Fire button while working the joysticks. I figure I could wire them in with one IO line. Two options: Use analog pin and resistor ladder. Or could have then tap into the same IO lines as the COLs of the keypad and wire in the other side as if it was another ROW. Not sure yet, may start of simply stealing one Button on the keypad to cycle through pages of stuff…

Another Idea for gaining IO lines is to use some of the data pins on the Xbee. They can be both Analog or Digital… But: they are only 3.3v IO lines and the carrier boards do not condition these pins. Something to experiment with later.

As for HSERIAL. It does make it easier to handshake, however as you mention it appears to still appears to impact other bit bang functions such as serout. When I change the HSERIAL from 9600 to 38400 on the remote, I have problems with the serial LCD showing garbage. I need to point this back out to Nathan. I probably need to capture this in some simple program with logic analyzer. I may go back to no using HSERIAL on the remote, but instead use the serin rx\rts format that is supported by XBee and that Nathan made fixes for in build 1.0.0.12? But this does eat up an IO line.

That is all for now. Progress may be a bit slow this week as I have some other stuff going on. That is all for now.

Kurt

9

Are you talking about a panel shaft encoder?

these typically take just A & B lines; and if you can accept only turning in a single direction, then one line should do it.

Are these XBEE modules peer-to-peer? I’ve already gotten into Bluetooth on my 'bots. Bi-directional, but only master-slave. I suppose one could have a PC serve as a dispatcher of some sort. I haven’t gotten that far. I’d hate to have to shift to another physical layer at this time, but if there’s an advantage… Hay, I’d even spring for one of those DIY affairs!

You mention problems with HSERIAL and the LCD and 38400 baud rates, how serious is this? I want to get BlueTooth using HSERIAL. My current Bluetooth (BlueSmirf) is with C code, where I have several interrupts running (Baby RTOS).

Alan KM6VV

10

Hi Alan,

A quick note. I am about out the door heading to the dump…

The switch that Xan is using has a encoder that works very similar to the encoders on motors. That has an A and a B line as you mention. Wrote assembly language code for it earlier that took care of both directions. In addition the switch can be pushed in like a push button which is the third leg…

XBees can be Peer to Peer or can have coordinators. Depending on which types you use the can have many differnt typologies. There are differences in version 1.s versus 2s which are now called 2.5. The two different versions can not talk to each other. You can use them as a simple serial replacement or you can do many different things with them. I am just scratching the surface.

At 38400 I am seeing a few random characters on the display. It probably depends on how many characters are going in or out. When I tried 57600 I saw lots more. I do have an assembly language stripped down version of serin that I wrote earlier for Xan that uses a timer to clock the serial output which appeared to work. I may simply switch to that to take care of the LCD.

Kurt

11

Hi Kurt,

I think I’ve seen something like that before. And you certainly like to have the push switch available if it’s there!

Thanks for the XBee info. I’ll continue to follow the threads on it, I’d like to make some progress with my 'quad (and maybe and octopod) first!

You throw things away?

Alan KM6VV

12

Hi Guys,

Ive been following your discussions on developing an Xbee based control system. Ive been working on this exact setup for the past few weeks and happened to stumble on your conversations from google when i was looking for solutions. However im using this setup for my R/C heli.

Im using an Atom Pro 24, 60mW XBee and the small sparkfun carrier board. Im also going to use an external serial servo driver board. I know the atom can handle servos, but i suspect that if you start running hserin and hservo together, there are going to be timing issues - could be wrong but have had this problem before…I decided to not use the hardware serial yet as i think the data rates capable with standard serin/serout commands is enough, but i would like the option to get the full 115kbps capability.

I have used the Xbees before (got some series 106’s back in 2005, but using later model series 1’s now). Their identity selection setups work well for creating a reasonably secure line of communication. Im using the X-CTU software from Digi, but have used the AT command group from a terminal too - both work fine.

Ive used the shell of an old 36Mhz controller i had lying around and made a small proto carrier board for the atom.

I have attempted this project before a few years ago when i was just getting into programming. I used the early 106 model xbee with the low power (but cheap) PICAXE series of chips. I got it working on 4 channels, but the latency with the low power PICAXE was unacceptable. This was running at 4800bps. But i learnt from that that it does not take much to match the performance (and exceed) of the current R/C gear for a lower price.

Ive got some concerns with the sparkfun xbee carrier board. It is sold saying it can level shift 5v logic, but looking at the board i cant see how this works. You only need to level shift the transmit of course as the return line should work. In the past i have seen this done with a simple voltage divider on the transmit line, but ive only used this at slow data rates (9600bps).

Anyway, happy to trade notes with you guys as we go. More brains are better than one…Im in Sydney, Australia so ill work on it while you sleep!!

13

Hi Rotorman,

I am wondering as well about the Sparkfun one. For awhile they had a schematic up there, which did not work last week, now the product is not up on their website I am currently testing using board built by selmaware, which has it’s own LM2937 voltage regulator on it to get the 3.3 volts it wants, plus a big 20 pin dip chip for doing shifting of voltages. I was hoping that the sparkfun versino would work as it is maybe 1/3rd the size and about half the price.

Kurt

14

Kurte,

Im persisting with the sparkfun carrier board for the same reasons - i need something small and light. So far i have not had any luck with getting it to work, but that could be a few other things im doing wrong…

Ive followed the traces on the board. The dataout line on the board connects the transmit pin of the xbee directly to the dataout pin of the atom. The transmit led is driven on a branch off this to a pin on the voltage regulator that is at 3.3volts. So to me all this is doing is the led is operating on the difference = 1.7 volts. This does nothing to provide a level shift, but it limits the input current (i think?).

Reading round on the net others have found that provided you limit the current into the xbee it is 5 volt logic tolerant - opposite to the explicit advice from Digi.

I have a xbee working connected to a MAX232 running 5volt with the TTL output running through a voltage divider (no specific level shift chip). Had this running the range test in X-CTU fine at 57kbps with no misses.

So, up to the individual i guess. Personally, i like simple - if i dont need it, i dont put it in. I have been driving my xbee with this board and it is getting 5volt signals and has not smoked it - yet.

The data-in (data received from xbee) line on the board has what i suspect is a signal diode in series to protect it from being accidentally sent a transmit signal. I suspect this means the receive voltage coming back is 3.3volt - diode drop but have not confirmed this.

I have also bought a similar xbee carrier board from robotshop.ca. It has a similar design (brings all the CTS lines etc out tho), but i havent traced it all back yet to compare the differences. It definately does not have a proper level shifting chip on it either.

Question - what baud mode are you using to transmit from the atom to the xbee. Im currently using SEROUT pin,I9600,[data] as the xbee requires 3.3volt = 1, 0volt = 0 type logic with the line held high before and after transmission. Does SEROUT drive the line high after transmission or do you need a high command after the serout command to do this? Im not using a flow control line as have managed to get away with it in the past, at speeds up to 57kbps.

Ill experiment, but interested in how you are handling it.

15

Hi again,

Others up here are better at electronics than I am, so I won’t comment much about if the diode will be sufficient. Earlier I asked the people at sparkfun if you can pass it 6V, but I should have maybe said a 6V battery and they said that the onboard regulator should handle it…

I use the same serout or equivlent value for hserout. I would like to up this to a higher baud rate and yes serout will in this case will leave the output high. You can get away without using flow control if you have a strong enough hand shake such that you are always there in a serin when there is data being sent. If you want to have a little more flexibility in your code then using flow control allows you to have the built in hardware on the XBEE buffer up the inputs for you and only start returning it to you when you want it.

Kurt

16

Ok, now to correct some of what ive previously posted. A day of experimenting…nows the time for those really smart electronics guys amongst you to come out and add some knowledge, and correct any of my postulating.

So, something i got wrong that is blatantly obvious is that the LED’s on the regulated xbee boards are set to go on when the signal lines go low, not high so they cant be helping in the level shift issue at all.

Fact is that the sparkfun xbee regulated board doesnt do any level shifting. If you wire it directly to the pin of an atom, even the 3.3volt pin it does not work. The signal LED flickers, but nothing transmits. I suspect what is happening is that too much current is going into the xbee causing it to overload and protect itself, but i havent gone deeper into the inner workings of the xbee to confirm this. It appears from the notes of others that if you limit the input current, the xbee will work on 5 volt logic. But for the sake of one more resistor to make a voltage divider, you get both. So tomorrow im modifying the board with a voltage divider to confirm this theory. If this works, its still a good option. Will tell you tomorrow how i get on.

Working on code for doing the controls also, but got nothing good enough to show yet. I will persist with doing this without flow control first, as for me the buffering capability does not help. If it buffers, my heli is not getting instructions = bad. Helis need control inputs continuously to keep them flying. Even a pause for half a second is not good. This may mean in the end that an xbee is a bad idea for my heli - so be it, but i would have at least tried. I will potentially use dual xbees for bidirectional comms so that the controls are not interrupted.

17

Yep, others are better at the electrical stuff. But may not be important as it appears like Sparkfun has discontinued the product. Trossen still appears to have some in stock, but at least for me clicking on the schematic link fails… But there are other boards that do have proper level shifting, such as the Selmaware ones which are pretty large. Another one I have found is: adafruit.com/index.php?main_page=product_info&cPath=29&products_id=126 I don’t know anything about them, but…

Buffering the data can be a very good thing if it keeps you from losing a packet. I am not talking about holding the data for a second or two at a time, but maybe a several miliseconds. However currently I am not sure about using the RTS line. The beta version of studio I have appears to work as I would expect it, however when the RTS signal comes back up the XBEE still sends a byte or two before it stops as I believe on a PC the RTS means I am about full.

I tried again to change my Transmitter code to use RTS, but my packets kept getting screwed up (out of alignment with data bytes lost). I have a couple of options:

  1. If it continues that two bytes are lost each time, I could add 2 bytes of fluff at the end.

2)Go back HSERIN and take care of the LCD problems (I have the code for this)

3)Try without any flow control. Since currently I am getting prompts from robot could try to time it to get them correctly.

3a) Like 3) but with hack to maybe change which IO line the RX is on to one with interrupt, could send character that triggers interrupt, then wait a bit and then send packet. Some complications would be to make sure the first character got sent out (timeout on xbee) before the others of the packet was sent). I used something like this on the TV brat in S_IN…

That is all for now.
Kurt

18

Quick update: I received email from Sparkfun. It looks like the part has not been discontinued and is back up on their website. For some reason I can not load their schematic from website but they did send me one in email.

It appears like they are relying on the LED and a 1K resistor to lower the voltage…

19

Hi Guys,

I don’t know if I have much to add at this point, but I would not route 5v logic signals into 3.3v logic without a proper level converter. I’ve designed boards with mixed logic, and it’s a hassle! I was lucky enough to be able to find 5v tolerant parts in one instance; another interface was accomplished with the two-resistor voltage divider mentioned.

The fact that the product is discontinued makes me think they realized that the design was faulty.

diversity XBEE receivers? Could work! I remember the DIY receiver stuff had a second receiver, That’s the first time I’ve seen that approach outside of commercial or Amateur Radio applications!

Looking forward to hearing more on the implementation of XBEE!

Alan KM6VV

20

Ive got my xbee control system now up and communicating, just using a single channel at the moment for simplicity.

The sparkfun xbee carrier boards seem to work just fine (now that ive got everything there). I currently have them with 5 volt logic directly into the input lines (for the moment anyway - time will tell if it is detrimental…). I experimented with a voltage divider setup on the input, and it seems that (as i found before) 3.3volt logic can be a little marginal to drive it.

I am surprised this is working, as there is nothing that i can understand that is reducing the logic level. The ‘DIN’ and ‘DOUT’ leds are not doing anything - they are actually wired the opposite polarity so they come on with a 0 (0volts) and are driven off the onboard 3.3volt regulator. Im sure ill find out with time if this is healthy. To be honest, ive made some real stuff ups before and wired the xbee up accidentally the wrong way (data in the data out line etc) and they seem remarkably tough. And they should be - xbee’s are matured technology and have been around for a few years now in industrial applications.

So, up to you guys i guess, but ill stick with these - they are under US$10 and they are only as big as the xbee, perfect for what i want.

One thing to note is that to me the board is a little confusing with its labeling of the led’s. The wireless ‘receive data’ led is labeled ‘DOUT’, as in refering to Data out at the pin, not data out from the wireless. Had me a little confused.

Anyone else other than kurte actively working to get something going?