Ok, I think I have the starting and ending handshake working better.
xbee_taserial_support.bas (74.1 KB)
Thanks again Kurt!
It worked perfect! 8) I just want to do some more tuning on the control code and then I’ll do some more testing.
I didn’t got time to test your latest code more than a few minutes until my logic power on Phoenix went down. I’m thinking of removing the 9v batteries for the electronics and simply use the LiPo for the electronics too.
Hi Kurt,
I’ve done some more testing again. Especially with the single leg mode.
For a little time now, I’ve had a feeling that the resolution/response from the joysticks wasn’t the same as I got from the DIY RC. The single leg mode is a very good example where you need a relative high precision. And I must admit the difference was very visible in this mode. Using the DIY RC gave a very accurate movement of the single leg and it was pretty easy to adjust the movement of +/- 1 mm. But the DIY XBee version was much harder to control and the movement seemed a bit “choppy”, not the smooth accurate movement we want. I did a terminal serout debugging of the three SLLeg variables in the control file and the result proved my findings, the RC values varied very accurate with 1 mm precision while the XBee values varied with +/- 2-4 mm when doing small adjustments on the joysticks.
I have a feeling this has something with the byte size resolution of 1 channel you mentioned earlier. Do you have other suggestions whats causing this?
Not sure yet, maybe it has to do with the code only sending data if it moved enough (value difference at least 2). You can probably easily defeat that in the transmitter code and see if that is the difference. My guess that is what it is. Yes I am only doing one byte now, but from my own checking what ranges I was getting from my joysticks: 636-392, 630-416, 598-361, 638-426
I don’t think any of mine had a range of more than 256. To defeat the code in the transmitter, look at the code:
elseif (ABS(bPacket(i)-bPacketPrev(i)) > 1) ; BUGBUG:: will be able to set the threholds from robot...
fSendNewPacketMsg = TRUE
endif
And simply change it to say if the two values are not the same…
Kurt
Thanks Kurt!
That did the magic! Much smoother and accurate result.
Like you suggested I modified the code to this
elseif (bPacket(i)<>bPacketPrev(i)) ; BUGBUG:: will be able to set the threholds from robot...
fSendNewPacketMsg = TRUE
endif
May I ask why you didn’t do that from the beginning? 
I thought it would be nice to minimize how many packets were being sent, especially if the joysticks are just sitting there, and the values bounce back and forth between two values…
As you may have noticed in the code I also meant to add the ability to set it… Maybe I could still and/or maybe only when the joysticks are in some deadband zone.
Kurt
Ok I see what you mean. What if you monitored the joystick values over a certain amount of time (simply counting main cycles?), say about 5 second. Then start minimizing the amount of packets if the values did only change by +/-1 (like you did before).
Sounds interesting. My first attempt was just sort-of an experiment. Maybe It is not needed at all. Could also probably add a configuration page, which allows you set the slop factor, maybe 0-9 (default 0 or 1), could use other keys to set options: C - Center only (IE dead-band), D- Delay (like you mentioned)…
Not sure how high a priority that would be to do. Other things I would like to do include:
-
I want to get my SSC pass through working well.
-
Change the Destination select page: maybe in 2 modes. 1) like you have now, where you can type in the hex value. 2) You try to discover which robots are out there by doing a node discovery (ATND), and you choose the one you want from the list.
-
More configuration stuff: not needed for me as I am only one person with one remote running at a time, but maybe a way to change the channel numbers or the … to help minimize interference between users. Could be a compile time setting, could be a simple addition to the quick and dirty XBEE config program that is in the zip file, or could be configured through the remote. Many options: could have the remote/handshake protocol have the ability to tell a robot, to please change its own address to hhhh. Or maybe in the destination select, if you use the node discovery: we don’t connect using the 16 bit logical address, but instead connect using the 64 bit physical addresses which are unique…
-
VB: I have the simple program that can connect to the robot, but having two sliders to emulate a joystick is pretty lame. Would be more fun to have a control that works like a joystick. I see an example of it with the MSRS with the desktop joystick or some such name. Or better yet maybe interface in a real joystick (Don’t think I have one any more) or one of my WII controller, PS3?
…
Or now for something completely different…
I’ve been thinking the same, is it really needed? I feel its working very fine right now.
This would be a very useful option to have and a great alternative to having a BlueSmirf bluetooth adapter connected to the SSC.
I like your option #2, especially if you could choose between the unique ATNI name from every robot/XBee. Or a 3. option: What if the DIY remote do a node discovery (like your option #2) if it just find one robot it automatical connects to the active robot! If it find more than one robot the user must choose (of course ).
Isn’t this (almost) solved by selecting another PAN ID (ATID) that differ from the default value?
Personaly I like the DIY remote better for controlling the robots. But together with more advanced autonomous control with a vision software (RoboRealm?) the PC connection would a very useful option.
Thanks for the input Zenta,
Yah for now I think I will remove the code. Maybe later add it back in with timer stuff so if it only alternates for a few seconds then … But probably not high priority.
The SSC-32 thing just seems like it could be fun, if we could easily make it from your pc to be able to download new sequences and try them out, which makes the VB stuff sort of interesting.
Yes choosing a new PAN ID would solve it. Again for me no big deal as I am the only one here so no problems… Could be as easy as changing my little config program to be able to set the PAN ID of the XBEES when we configure the baud rate, etc. Or could add some configuration stuff to the remote, that allows the user to change the PAN ID of their remote and send that to the robot(s) as well… More work. Also easy is if we connect by using the information returned by the ND command to connect by the 64 bit addresses which are always unique.
The VB stuff is a way for me to make sure things are working OK and it does open the opportunity to integrate in some other stuff, like Wiimote. As you said some could also integrate the video feed in as well. I also like to experiment up there as it is easier to do things in VB than in BAP basic. More on this in a second.
Displaying the available Node names and optionally auto connecting… (Note: most may want to ignore these ramblings 
)
How to code??? I would like to issue the Node discovery (ATND) command and present the list to the user on the LCD display so I issue the command, which returns data like:
[code]atnd
31
13A200
403C59FF
2C
Kurts CHR3 hex
34
13A200
403CAC52
3E
Kurts Rover
[/code]
For each XBEE if finds it returns several lines of data, each line ended with a CR. (MY, Serial High, Serial Low, signal strength, Node Identifier) It also has an extra CR after the Node Identifier. The list is ended if the next line is again just a CR. The questions in coding are:
-
how to read these lines in. With Hserin can use the formating stuff. Not sure, but could be as easy as:
hserin [hex wMy, hex lSN.highword, hex lSN.lowword, hex wSS, str abNI\20\13], with a little fudging for making sure how the different CRs are processed. Will try it out. For my input, I would need to do conversions of the hex values again no big deal. -
How to display on the LCD display. 2 lines of text, Do I simply show 1 line on the bottom line, then in N seconds show the next… Do I sort-of scroll them between the two LCD displays…
-
How to store the text. This is where VB is easier. (Just add it to List box) or New string, or struct… About the only legit way to do it is to define some big buffer that I manage the strings in. Thought about writing my own versions of malloc but not sure where, again I could just define some buffer, like:
dBuff var byte(256) and then allocating data out of there. I thought about trying to use the memory that is not used, but I think Nathan uses that. I wrote a real simple program:
[code]XR7 var long
XR6 var long
pp var pointer
x var byte
main:
mov.l er7, @XR7
mov.l er6, @XR6
pp = @x
pause 1000
serout s_out, i9600, [13, "ER7: ", hex xr7, " ER6: ", hex XR6, " P: ", hex pp, 13]
goto main[/code]
To see how the memory was allocated. I believe that the valid Ram Addresses for the 2K on BAP is: F780 -FF7F. So the output from the program showed:
ER7: F790FEFE ER6: CC40C98 P: 2F78CWhich makes sense. I defined 12 bytes of data before B, so the address of F78C looks correct, I know that ER7 is used for two pointers. The low half is for the standard stack when we do calls: FEFE The high word I believe is used for a Basic Stack that Nathan uses and it is allocated; F790 which is just after the X variable…
- Could also decide everything is good enough for now as it is working for you and me and work on some other projects.
Thanks again
Kurt
Hi again Kurt,
I’ve read all your “ramblings” and find it very interesting, as always. 
Very often you only power up one of the robot you want to control so having the auto connecting function working would be awesome and very convenient.
Another feature that would be very easy to implement (I believe even I could make that kind of code ) : a simple “scroll and select your robot” function. I would guess most of us don’t build or buy a new robot very often, so just making a list in the program where you can scroll (using the up/down cmd btn) and select the robot you want to control would be good enough. The “robot list” could simply be updated in the .bas program if you wanted to add a robot/XBee module.
I have been playing around with the code. I do have a test program now issuing ATND command correctly and caching the data in memory, but the code looks like C… to me. I was using assembly language to try to hold the data for MY(16 bits) Serial Number (64 bits) and Node Identifier (String maybe limit to 12 characters (display My and string and fit in 16 byte LCD display).
Then I had a different idea - The Atom Pro has a 4kb EEPROM on it. So I could use some of this memory. Could probably even waste some as I think we are using 4 bytes currently…
I could define a max number of Robots we will remember by default: like 10. Then I can simply be sloppy, I could start the data at some EEPROM location, like: 1000. So if I don’t worry about compressing the data. I would only use up: 10(2+8+12)=220 bytes. When we enter the Select robot mode, I could either automatically do a query or use a key for it. By default I think the query would not remove old items. It probably would update items (Serial Number already known but different My or Title), or if the item is not there it would be saved to EEPROM. Maybe use keys Or maybe right joystick to scroll through the list of known items. Hitting Enter selects that one as the current one… If we end with items we no longer want in the list, could maybe use a key like (D) to to delete it…
Well I guess I need to get to work and try it out.
Kurt
Hi Zenta,
I hope you are have a nice Holiday season.
A quick update. I think I merged in the couple of changes you mentioned in the phoenix code. I also implemented the other way to select a robot. In this mode it will display your current list of robots. If you have a new one to add, make sure it is turned on and in this mode, you hit the “A” key and the code will do an ATND command and query for all of the nodes that are out there and add them to the list. You can scroll through the list moving the right joystick up and down. If there is something in the list you don’t want there, you can hit the “d” key to delete it. Hitting the logical new Enter key will save away the changes into the EEPROM of the Atom Pro.
So far I am liking how it is working. May end up removing the other way of entering the DL. Currently the protocol is still using the 16 bit MY values of the XBEES to connect. However I am storing away the unique 64 bit serial numbers. So I can easily change the transmitter code to use these addresses. I can also change my READY message to instead of sending the 16 bit for the robot to use to talk back to the transmitter, I could transmit the 64 bit address for them to use as well. The only changes to the code would be the handling of this command and startup code to retrieve the 64 bit address and instead of only using the 16 bits to set ATDL, you would use the low 32 bits to set ATDL and the high 32 bits to set ATDH.
I am currently running my transmitter using my functions and a RTS line. I do have the code in place as wll to use HSERIAL, with uncommenting one define in the source file. I will test this out probably tomorrow.
Hi Kurt,
Thanks for the update!
We’ve had a “white” christmas this year, so I’m doing fine. I hope you have a nice christmas season as well. I’ve not had much time for robotics though.
I’m still waiting for more XBee modules from Trossen, they had a backorder on the regulators. I’ll probably test your new code next year.
Your changes sounds great! Does the actual changes in code only affect the xbee_taserial_support.bas and the diy transmitter.bas files? I would appreciate an non-RTS version too
Thanks for sharing your work!
Thanks Zenta,
I am Glad you had a nice Christmas. We did have a nice quite Christmas. No snow this year.
Yes so far the main updates were only in the two files you mentioned. I did make the couple of changes you talked about to the main phoenix code. Will test with the HSERIAL version in the next couple of days. Spending more time right now trying to review the Work In Progress BAP manual, which is coming along. You can find that up on: forums.basicmicro.net/viewtopic. … 6cc42da5b4
Also playing a little with the Axon2 (AVR640). Not done much yet, just starting to play. First thing I might do is to interface the XBEE with it. Should be easy as you have 4 USARTS… But that is a different story!
Kurt
Hi Zenta,
Ok, I made progress with the Transmitter. You might try the updated transmitter file
Hi Kurt,
I barely got time for testing it before we went for the little vacation. But I’m sorry to say that I still didn’t get the new version to work with the non-RTS version on the DIY. I probably need to do some debugging when I’m home again.
Sorry,
I will debug it some more later. I have it running using the HSERIAL version on mine, but maybe I should unplug the RTS line to make sure that I am not using it by accident. Besides soon I will be again working on it to get the SSC stuff working better.
Have a nice vacation. Let me know when you get back so I will update the library again
Kurt
Thanks Kurt!
I’ll let you know when I’m ready for more testing. I’m a bit puzzled that it work ok for you though, maybe removing the RTS wire on your DIY remote just to be sure would be an idea (as you suggested).
Welcome back! Yes I am running my DIY right now on the HSERIAL version and I do have the RTS line unplugged. So far I am seeing some issues of the LCD getting some strange characters from time to time, but it is controlling my HEX as far as I can tell OK. So I may need to convert some of the remaining serout commands to taserout…
So first I need to know what is not working for you. If you use the old input method to choose your robot are you having any luck? Is your robot showing up in the list if you try the new input method? If so do you hit the logical Enter key to have it save both your selecting and the list away?
I am having some interesting testing issues with the list of things that come back from the ATND command. I am currently playing around with the AXON2 and converted my communication code to C. At first I was not getting anything, that is when I found out others had problems with the Sparkfun interface and the Axon. It appears the axons UART does not get the low level low enough for the XBEE, so swapped around to use one from Selmaware. Now it appears to be starting to work… Boy am I rusty in C… But back on track. So I wanted to add the “DeBrat” to my list of robots and then did the “A” to have my remote do a scan and it did not find it. Tried again, still did not find it. Went to back XBEE with sparkfun USB and X-CTU, entered the ANTD command and it did not return it as well. Turned on my Hex robot, issued the ATND and it found the hex not the other one. Hosted the XBEE that it was not finding back in my test BAP setup, issued the ATND, still did not see it. Put it back on other system, turned on Hex again tried it, failed, tried again and DeBrat showed up with my CHR. So I went back to the remote and tried “A” command again did not get it, 3rd try it finally showed up, so I saved it away. So for whatever reason some XBEES don’t respond some of the time to the ATND command…
What am I going to try next?
-
Maybe some XBees are slow with regards to the ATND command. So I am going to try changing the timeout for the search from the default which I think is 2.5 seconds to maybe 4-5 seconds, using the ATNT command and see if that helps. (OOPS - I tried with X-CTU and find that I would need to change the firmware from the 1084 version to something like 1.A0+ Not sure what all the differences are with the A series of firmware…
-
Maybe change my XBEE config program to allow you to choose a Channel and a Pan ID and allow you to choose them to update all of your XBees. Maybe they get some interference on some channels, so try different ones. Not sure if that will help or not. But at a minimum I will try to see if maybe some have different versions? Not sure why some things would be different?
Well now I need to get busy and figure out what is going on!
Kurt
P.S. - I hope you had a nice mini vacation and happy almost new year!