Lynxmotion Tech Support

Here is a place holder picture, until things are back in one piece:


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: http://www.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! 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.

Kurt

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.

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...

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:

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

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 ) 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.

_________________
[b]Kåre Halvorsen, Zenta[/b]
-----------------------------------------
Zenta's blog
http://zentasrobots.com/
Zenta's YouTube channel
http://www.youtube.com/ZentaOlbaid
-----------------------------------------

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:


Kurt

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.

_________________
[b]Kåre Halvorsen, Zenta[/b]
-----------------------------------------
Zenta's blog
http://zentasrobots.com/
Zenta's YouTube channel
http://www.youtube.com/ZentaOlbaid
-----------------------------------------

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

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

_________________
[b]Share, Use and Improve![/b]
Digging trough: [i]Theory of Applied Robotics: Kinematics, Dynamics, and Control[/i]
Xan's YouTube Channel
http://www.youtube.com/xanore

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:
<packit id><checksum><Cmd><Cnt of extra data>

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:
<Packit id><checksum>
<buttons 1><buttons 2><RJoy LR><RJoy UP><LJoy LR><LJoy UP><Right slider><Left slider>

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

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

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

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

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

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

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!!

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

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.

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