DIY Remote Control XBee controller for Robotics

[km6vv]

I’m wondering if we need to implement a checksum. It could work the same as the PS2’s checksum.

Thanks for posting your code.

Alan KM6VV

@kurte

Not sure where to talk about this, but after Robot Dude posted information about the Binary input to the SSC-32 and a couple of Private Messages, I took my first pass through converting my DIY Phoenix code to convert to binary. I have not had much time to test it yet. Some of it appears to work, but I am having a few legs maybe not moving 100% correct.

Zenta (and others), I thought I would post the updated file that I hacked for this in case you would like to try testing/fixing it. I hacked up both for using TASerial for high speed and for using the standard serouts… To find the changes look for code that is ifdefed under
SSC_BINARY

Kurt

[zenta]

Hi Kurt,

Thanks for sharing your work Kurt! 8)
I’ve just tested the binary mode and it worked very fine! (Just testing a few minutes though) I’m looking at the code you posted in the other binary thread… Did you try to break up the servodriver for the XBee version too? Just curious… :wink and it would be fun to measure (logic analyzer) how much time we are saving here.

[kurte]

Hi Zenta,

Thanks good to hear. I will migrate it back into this one real soon as well. First I was going to make a PS2 version that runs at the 115200 baud rate so others without the DIY remote can try this mode as well…

Took a break this morning to take the dogs to the beach to walk around. Today it is nice and sunny and 50 degrees (10c), which is warm for this time of year!

Now back to work

Kurt

[zenta]

@kurte

Thanks good to hear. I will migrate it back into this one real soon as well. First I was going to make a PS2 version that runs at the 115200 baud rate so others without the DIY remote can try this mode as well…

Took a break this morning to take the dogs to the beach to walk around. Today it is nice and sunny and 50 degrees (10c), which is warm for this time of year!

Now back to work

I woud love to try out the PS2 version too (if I had one working… )

10c ! Sounds great! We have ice, snow and -2c right now.
The dogs…? How many do you have and what breed?

Looking forward to try out the updated code!

[kurte]

@zenta

I woud love to try out the PS2 version too (if I had one working… )

Yep, I have had a few stop working in the past. Need to figure out why my old and trusty Sector 7 stopped working, but the Lynxmotion one is working for me. In my next order I will probably order a couple of the receivers, now that they sell them seperatly.

@zenta

10c ! Sounds great! We have ice, snow and -2c right now.
The dogs…? How many do you have and what breed?

We have two Collies. Jake, our older male is now over 10 years old and is a very big (~100 pounds) Sable (like Lassy). Clare is 5+ years old and she is a tri-color (mostly black with white ruff and brown on her face)[attachment=0]Jake-and-Clare.jpg[/attachment]

Picture is a few years old…

Kurt

[kurte]

Hi again Zenta,

I tried to merge in the changes, although I left the code in to check each servo to only ouput, when it has changed, Not sure if that helps or not, may change later… May be slightly faster to do it the way I did it on the PS2 version in normal move case… May check later…

Also did not even try to compile the changes for non hsersial option…

Kurt
phoenix_v21k.bas (47.7 KB)
phoenix_control_diy-xbee.bas (14.3 KB)

[zenta]

Hi Kurt,

I just did some testing again, but not for long… One of my 645’s broke down again (while Phoenix was on the stand), this is the 3rd servo in a relative short period of time… argh! So I’ll have to replace it before doing some more testing. But so far I measured the time from the Gosub ServoDriverStart to the start of main loop to take about 9,5 mS… And the ServoDriverCommit took around 0,5 mS

Looks like the pause command can be modified to this:

pause (PrevSSCTime - CycleTime) MIN 1

No need for a -xx mS anymore! I did a short test and it seemed to work ok.

Thanks for your help Kurt!

[kurte]

Sorry to hear about your servo!

Will make the chnage you suggested. Will also probably get rid of the extra code in this version for only ouput pins that change. May slow things down versus other version when doing moves…

Kurt

[zenta]

Hi Kurt,

I’ve just replaced the servo and Phoenix is walking… err… running again! I adjusted the NomGaitSpeed to 60 mS for the 12 step ripple and the 8 step tripod. I believe faster servos are needed now I think a complete cycletime are down to around 50 mS and that should help Xan on his TA work.

BTW, the code worked flawless

[kurte]

That is great!!!

I will update the times on mine as well!

Kurt

[zenta]

Hi Kurt (and other lurkers ),

Lately I’ve been working on the code for Phoenix and T-Hex.
I’m a bit unsure where to post the code; in this thread, Xan’s Phoenix code thread or in my T-Hex thread. But since the code I’m using is Kurt’s hacked XBee/binary SSC version of Xan’s V20 code I feel this might be the correct place. Anyway, I’ll post some information in the other threads too and linking to this one.

Here are the updated code I’m currently using on my T-Hex and Phoenix. I’ve just zipped the robot directory I originaly got from Kurt.
Robots.zip (561 KB)

I’ve tried to summarize whats new to the V2.1k code: (Please correct me if I’m wrong on something Kurt)

;NEW IN V2.1k ; - Added XBee control and fast serial mode (Kurt) ; - Added binary mode for SSC32 (Kurt) ; - Inverted X direction in single leg mode (Kåre) ; - Modified sync part between BAP ans SSC while walking (Kåre) ; - Removed different gait types (Kåre) ; - Added constant (later variable?) for BalanceDiv Factor, other values then 6 can be used. ; - Moved GaitInMotion calc to the GaitSeq sub

Kurt, does this code also work fine with the PS2 controller?

[kurte]

Hi Zenta,

I believe it would work with the PS2 as well. But I also did a fresh change for the binary changes that I did run specificially with the PS2… I will check it out more this weekend when I have some time.

Kurt

[zenta]

Hi Kurt,

I just got a question at Trossen if Phoenix and A-Pod can communicate with eachother. In theory I believe that is possible. I’ve been thinking of controlling two robot at ones using one robot as the “Master” and the other as a “Slave”, where the “Master” robot send control commands to the “Slave”. Do you think that would be hard to do?

Oh another thing, since I’m using LiPo batteries on the robots I would like the robot to send the actual battery status/voltage every 2. minutte or so if the voltage drop below 6,5 volt (just as a warning). Do you have any tip on how to send the value, do I have to convert the value into a text string format first? Your code easily explain how to send general textstrings back to the transmitter, and I’m using that feature alot on A-Pod (very useful, thanks). I’m just a bit unsure when it comes to sending simple variable values…

[kurte]

Good morning Zenta (although probably afternoon or evening for you)

@zenta

I just got a question at Trossen if Phoenix and A-Pod can communicate with each other. In theory I believe that is possible. I’ve been thinking of controlling two robot at ones using one robot as the “Master” and the other as a “Slave”, where the “Master” robot send control commands to the “Slave”. Do you think that would be hard to do?

It would take some work to reorganize the code some. That is all of the code for the transmitter is in a #ifdef for the transmitter. Also this is when it would be good to switch the XBEE into packet mode instead of the text mode we are in now. That way you don’t have to keep switching into command mode to change who you are talking to.

If this is something you wish to do, I would be willing to help. I have wanted to do this for awhile as for example I wanted the ability to have my robot talk to both the remove as well as the PC. This way it can output lots of debug information or the like…

@zenta

Oh another thing, since I’m using LiPo batteries on the robots I would like the robot to send the actual battery status/voltage every 2. minute or so if the voltage drop below 6,5 volt (just as a warning). Do you have any tip on how to send the value, do I have to convert the value into a text string format first? Your code easily explain how to send general textstrings back to the transmitter, and I’m using that feature a lot on A-Pod (very useful, thanks). I’m just a bit unsure when it comes to sending simple variable values…

There are three different things you can do.

1. call XBeeOutputVal with a byte to be transmitted - this value will be displayed on I believe on the right hand side of the second line.
2. call XbeeOutputString - which will send the string to the remote to be displayed…
3. call XBeePlaySounds - (I am not sure if this is up in the version you have) I added this when I was playing with the Brat with Axon2(no speaker) and later with the phoenix with Arc32 (before I added a speaker). If this is not in your version and you would like it, let me know…

Kurt

[zenta]

@kurte

Good morning Zenta (although probably afternoon or evening for you)

LOL, good afternoon sounds pretty accurate.

@kurte

It would take some work to reorganize the code some. That is all of the code for the transmitter is in a #ifdef for the transmitter. Also this is when it would be good to switch the XBEE into packet mode instead of the text mode we are in now. That way you don’t have to keep switching into command mode to change who you are talking to.

Ah, I remember you talked about the packet mode before. I think I’ll have to find some docs to read more about that one time.

@kurte

If this is something you wish to do, I would be willing to help. I have wanted to do this for awhile as for example I wanted the ability to have my robot talk to both the remove as well as the PC. This way it can output lots of debug information or the like…

I’m not sure if I’ve the skills to do it though, so if you ever find time to take a look at it I would be happy to test out the code. But take your time, I’m in no hurry. There are so many other things to do at this side of the year.

If you want I can post the latest code I use for Phoenix, I’ve done some changes to the BodyIK, added and changed some variables for shifting the centerpoint of rotation (CPR).

@kurte

There are three different things you can do.

1. call XBeeOutputVal with a byte to be transmitted - this value will be displayed on I believe on the right hand side of the second line.
2. call XbeeOutputString - which will send the string to the remote to be displayed…
3. call XBeePlaySounds - (I am not sure if this is up in the version you have) I added this when I was playing with the Brat with Axon2(no speaker) and later with the phoenix with Arc32 (before I added a speaker). If this is not in your version and you would like it, let me know…

Thanks for your information Kurt! I’ll see what I find out.
I’m not sure if I’m using your latest version when it comes to the playsound command since I removed the speaker on my DIY remote.

[kurte]

@zenta

I’m not sure if I’ve the skills to do it though, so if you ever find time to take a look at it I would be happy to test out the code. But take your time, I’m in no hurry. There are so many other things to do at this side of the year.

Actually I would trust you do have the skills, the way you can make all your robots move , but I understand and will take this on later…
I started this at one point on the Atmega, so I will take a look and see what I can come up with.

@zenta

If you want I can post the latest code I use for Phoenix, I’ve done some changes to the BodyIK, added and changed some variables for shifting the centerpoint of rotation (CPR).

That would be great!

@zenta

I’m not sure if I’m using your latest version when it comes to the playsound command since I removed the speaker on my DIY remote.

Yep that probably would not help you much

Kurt

[zenta]

@kurte

Actually I would trust you do have the skills, the way you can make all your robots move , but I understand and will take this on later…
I started this at one point on the Atmega, so I will take a look and see what I can come up with.

Sounds great Kurt!
When it comes to the ASM parts I tend to loose track easily, lol.

@zenta

If you want I can post the latest code I use for Phoenix, I’ve done some changes to the BodyIK, added and changed some variables for shifting the centerpoint of rotation (CPR).

@kurte

That would be great!

I’ve attached the latest code. I’ve not commented all parts.

;NEW IN V2.1k ; - Added XBee control and fast serial mode (Kurt) ; - Added binary mode for SSC32 (Kurt) ; - Inverted X direction in single leg mode (Kåre) ; - Modified sync part between BAP ans SSC while walking (Kåre) ; - Removed different gait types (Kåre) ; - Added constant (later variable?) for BalanceDiv Factor, other values then 6 can be used. ; - Moved GaitInMotion calc to the GaitSeq sub ; - Added offset variables for Z and Y rotation, changed TotalX,Y,Z -> CPR_X,Y,Z

If you look into the control file I’ve added a simple SmoothControl Sub:

[code]; SmoothControl
; This function makes the body rotation and translation much smoother while walking
;
SmoothControl [CtrlMoveInp, CtrlMoveOut, CtrlDivider]
IF Walking THEN
IF (CtrlMoveOut < (CtrlMoveInp - 4)) THEN
CtrlMoveOut = CtrlMoveOut + ABS((CtrlMoveOut - CtrlMoveInp)/CtrlDivider)
ELSEIF (CtrlMoveOut > (CtrlMoveInp + 4))
CtrlMoveOut = CtrlMoveOut - ABS((CtrlMoveOut - CtrlMoveInp)/CtrlDivider)
ELSE
CtrlMoveOut = CtrlMoveInp
ENDIF
ELSE
CtrlMoveOut = CtrlMoveInp
ENDIF

return CtrlMoveOut[/code]

That did the magic when doing body, head and mandible movement combined with walking on A-Pod.
EDIT, forgot the file:
Phoenix_V21_BinarySSC.zip (45.2 KB)

[zenta]

Hi Kurt,

Thanks for the tip about calling the XBeeOutputVal. I’m using that continously (every 15. main cycle) for updating the transmitter with the actual LiPo voltage value. This is the sub I’m calling from the main loop (after the GOSUB ControlInput):

[code];[CheckLiPoStatus]LiPo safety warning!!!
;If voltage drop to 6 volt give audio warning!! (The Polyquest LiPo must not go under 5,6v!)
;5,5v = 284
;6,0v = 310
;8,4v = 432
CheckLiPoStatus:

adin 17, wLiPoVad ; Read VL (AX1)
IF (wLiPoVad<310) THEN
IF(HexOn) THEN
'Turn off immediately!!
BodyPosX = 0
BodyPosY = 0
BodyPosZ = 0
BodyRotX1 = 0
BodyRotY1 = 0
BodyRotZ1 = 0
TravelLengthX = 0
TravelLengthZ = 0
TravelRotationY = 0

  SSCTime = 300
  GOSUB ServoDriverStart
  GOSUB ServoDriverCommit
  HexOn = 0
  LiPoLowVoltage = 1
  Sound P9,[100\2000,100\3000,100\4000,100\3000,100\2000] ;Major Warning beeper!
ENDIF

ENDIF
IF (LiPoLowVoltage) THEN ;Give a warning continously, since the voltage probably will raise a little when servos are turned off
Sound P9,[100\2000,100\3000,100\4000] ;Warning beeper
HexOn = 0 ;Lets keep it turned off
ENDIF
bLiPoV1 = ((wLiPoVad - 284)*c2DEC/508)+ 55 ;Calculate actual voltage with one decimal (fixed point)
;Send the voltage value to the transmitter every 15. cycle:
IF (LiPoCycleCnt = 15) THEN
GOSUB XBeeOutputVal[bLiPoV1]
LiPoCycleCnt = 0
ENDIF
LiPoCycleCnt = LiPoCycleCnt + 1

return[/code]

This code work very well and its great to know the actual battery status all the time.

I did only do some small changes to the DIY_transmitter.bas:

DisplayRemoteValue[bVal] ; Make sure we are in the right mode to display the data if (TransMode <> TMODE_DATA) AND (TransMode <> TMODE_NORMAL) then ; Don't display the value when in TMODE_NORMAL either

One thing I’ve noticed is that displaying a byte value occupied 4 digits on the LCD display. I believe this part in the DoLCDDisplay sub is the reason for that?:

; May later handle +- types of numbers abLCDBuff(4) = dec4 bLCDNum\4
I did some trial and error by entering 3 instead of 4, it did almost work but I got some strange symbols on the LCD too. I believe its easier to ask you how to modify your code so that one byte value only take 3 digit of space on the LCD. Any tip?

[kurte]

HI Zenta, glad it is working for you.

I think you are talking about this code:

; May later handle +- types of numbers abLCDBuff(4) = dec4 bLCDNum\4 bLCDChar = 4 while (bLCDChar < 7) and (abLCDBuff(bLCDChar) = "0") ; reuse the passed in char field as an index abLCDBuff(bLCDChar) = " " ; remove leading zeros bLCDChar = bLCDChar + 1 wend cbLCDOut = 8
If you change this code from 4 to 3 characters I think the code would then be:

; May later handle +- types of numbers abLCDBuff(4) = dec3 bLCDNum\3 bLCDChar = 4 while (bLCDChar < 6) and (abLCDBuff(bLCDChar) = "0") ; reuse the passed in char field as an index abLCDBuff(bLCDChar) = " " ; remove leading zeros bLCDChar = bLCDChar + 1 wend cbLCDOut = 7

Kurt

[zenta]

@kurte

If you change this code from 4 to 3 characters I think the code would then be:

; May later handle +- types of numbers abLCDBuff(4) = dec3 bLCDNum\3 bLCDChar = 4 while (bLCDChar < 6) and (abLCDBuff(bLCDChar) = "0") ; reuse the passed in char field as an index abLCDBuff(bLCDChar) = " " ; remove leading zeros bLCDChar = bLCDChar + 1 wend cbLCDOut = 7

Thanks Kurt!
That worked very fine.