Xan's Phoenix Code

[kurte]

Thanks,

I probably still need to update the angles min/max. I probably need to look through the code to figure out what they are used for and what they are referenced off of. For example are the angles based off of the center of the robot or the actual values for the servos…

Then the fun is to figure out more how the code is working and hopefully integrate with your stuff. Also maybe integrate more of the other capabilities from the powerpod…

Kurt

[brlippincott]

Kurte,
The bot looks great!! I think that is the first round hex I’ve seen using this program. Anyone seen any others?
I can only hope to get my video clips to upload as well. Still need to input all the same info into my hex, probably while I’m waiting for the BotBoard II to arive.

[kurte]

Thanks,

This evening after diner I had some more fun and I merged all Three of Xan’s programs into one. I can probably optimize it more later, but it was not difficult. I simply extracted out the three different Gait functions and renamed them (RipGait, TriGait, QuadGait) and then extracted out the sequences of code that called these and put them into an if then else logic. I then added some simple code that when you press the X button on the Ps2 controller it would cycle through the different Gates. Currently I think I like the Quad Ripple the best.

Tomorrow assuming I have time, I will try integrating in my Laser6 RC controller.

Xan, your code is a lot of fun to play with!

Kurt

[pyrrhicpk]

Hi Xan,

I just wanted to ask if I could use your Atom pro code with PC? Your code is meant to communicate with either Wii or PS2, but unfortunately I dont have either

I was wondering if there could be some way to map the keyboard keys in-place of PS2 section in the code and communicate via BlueSmirf over blutooth connection. Does this sound logical? or I dont have any other option than getting either a PS2 or RC?

Thanks,
Umar

[psymon]

@pyrrhicpk

I just wanted to ask if I could use your Atom pro code with PC?

The code for Wii control will work with a PC. The Wii Controller is hooked up to the PC via bluetooth and then the PC forwards that onto the bot (bluetooth again).

I belive Xan wrote a little wrapper for the Wii controller, intend to do something similar myself using delphi, for keyboard or mouse control etc.

I awaiting Xan’s return to the forum to see if his Black Widow code for the Wii made it to V1.1 (gait implemented)

Psymon

[xan]

Hi all,

I hadn’t had a lot of time this weekend so I was surprised to see the amount of activity

Hi Zenta,

@zenta

I used a scoop and another Basic Atom Pro to measure a port (I used P15).
Snip from code: (This example measures how long time it takes to read all RC channels)

Thanks for letting me know how you measured the timing. I was thinking of buying a scoop or logic analyser. A second hand scoop is easy to get for a decent price. Logic analysers are a better measuring tool for this but its hard to get a logic analyser for a good price. But I bought myself a new (second hand) car so this has to wait for a little while

I’m looking forward to see your balance system working in realtime! I bet it look Awesome!!

Hi Psymon,

@psymon

I see in this video
youtube.com/watch?v=NMtifBKX3kE
You have a gait implemented with Wii control, thought i’d ask if you could post that code revision before i work through adding the bluesmirf code into the Phoenix PS2 Code.

I want to get the new revision (1.2) ready as soon as possible. But it’s been very busy for the last week and the next one. I’ll try to get it done as soon as possible but I can’t promise anything.

But this doesn’t have to hold you back from using the current version and get the BlueSmirf to work with it. The code is made using subparts, if you’ve got it ready you can easy take it out and put it in the new release. You can find the BlueSmirf Wii code on my project page. You should add some code to read in more buttons since the new version uses more buttons. I’m sure you’ll figure it out by looking at the other buttons.

Hi Kurte,

@kurte

Ok, today I finally got my hex back in one piece. I swapped in a BB2, the SSC32 was updated to an ATMEGA128 and I installed a new Lynxmotion PS2 controller and cable… I used the newer tutorial to make sure I had everything back on properly (lynxmotion.com/images/html/build99c.htm. At first my PS2 controller did not work properly, but I found I plugged in the cable backwords (p12-15). I was temporarily confussed by Figure 7 in the tutorial as I think the picture may be wrong… But this is a different issue. Now It is working.

I used the same tutorial without any problems. The Phoenix tutorial shows the same direction The only thing that I know is that the colours of the wires changed a bit between the current and a older version of the remote. But I’m glad that you’ve got it working!

@kurte

I probably still need to update the angles min/max. I probably need to look through the code to figure out what they are used for and what they are referenced off of. For example are the angles based off of the center of the robot or the actual values for the servos…

The min/max angles are not used in the calculations. Just before the positions will be send to the SSC there is a check. The check will limit the position to be sure that the servo wound be forced into a position that is mechanically not possible.

@kurte

Then the fun is to figure out more how the code is working and hopefully integrate with your stuff. Also maybe integrate more of the other capabilities from the powerpod…

Sounds great! I’m curious to see what will come up. I hope you will share your findings.

@kurte

This evening after diner I had some more fun and I merged all Three of Xan’s programs into one. I can probably optimize it more later, but it was not difficult. I simply extracted out the three different Gait functions and renamed them (RipGait, TriGait, QuadGait) and then extracted out the sequences of code that called these and put them into an if then else logic. I then added some simple code that when you press the X button on the Ps2 controller it would cycle through the different Gates. Currently I think I like the Quad Ripple the best.

That’s the fast way that I’ve used to check them out quickly. The new version (1.2) will have a single gait sub which covers all. More coming up…

@kurte

Xan, your code is a lot of fun to play with!

Thanks, I’m glad to hear that you enjoy it!!

Hi Umar,

@pyrrhicpk

I just wanted to ask if I could use your Atom pro code with PC? Your code is meant to communicate with either Wii or PS2, but unfortunately I dont have either

I was wondering if there could be some way to map the keyboard keys in-place of PS2 section in the code and communicate via BlueSmirf over blutooth connection. Does this sound logical? or I dont have any other option than getting either a PS2 or RC?

Off course it is possible to work with something else. I think if somebody has got enough time and the necessary resources the can build almost anything! 8)

The Wii version works like this. I connect a Wii remote to my PC using Bluetooth. Then I’ve got a small program that I’ve written myself to read out the data of the wii remote. I convert this data that it can be send using the serial port (BlueSmirf connection). I did add a checksum byte to filter the incorrect frames.

The frame that I use looks like this:

<Startbyte $FF> <WiiMoteX> <WiiMoteY> <WiiMoteZ> <NunChukX> <NunChukY> <NunChukZ> <JoyX> <JoyY> <Butt1> <Butt2> <Checksum> They are all bytes. You can check out the receiver part by looking out at the Wii remote code that I’ve mentioned earlier in this post. You will need to write a program on your pc to convert the keyboard hits to the frame that you can send to the serial port.

If you don’t have any programming skills you can do it the easy way and use hyperterminal. You can send keys using hyperterminal and let the code react on that. This isn’t pretty but it should work…

Xan

[pyrrhicpk]

Hi pysmon,

I want to control the bot just through the keyboard over bluetooth connection. I am familiar with programing languages, but at the moment I have no idea which direction to start with. Xan mentioned that the data needs to be converted to frames which could then be sent to serial output. Here what does this “frame” represent? Does that corresponds to a SSC-32 like command encrypted in some form? And what methodology to be used to determine the required frames from keyboard key presses?

I belive Xan wrote a little wrapper for the Wii controller, intend to do something similar myself using delphi, for keyboard or mouse control etc.

what is the workflow of that wrapper? Can you plz give some explanation. I hope I could implement it in visual basic.

Thanks a lot,
Umar

[robotdude]

@kurte

I had everything back on properly (lynxmotion.com/images/html/build99c.htm. At first my PS2 controller did not work properly, but I found I plugged in the cable backwords (p12-15). I was temporarily confussed by Figure 7 in the tutorial as I think the picture may be wrong… But this is a different issue. Now It is working.

Um, well… It’s actually figure 8-2 that is blatantly wrong! We are fixing it.

[snailkeeper]

We’ve corrected Figure 8-2 - sorry for the error!

[psymon]

Hi Umar

@pyrrhicpk

Xan mentioned that the data needs to be converted to frames which could then be sent to serial output. Here what does this “frame” represent? Does that corresponds to a SSC-32 like command encrypted in some form? And what methodology to be used to determine the required frames from keyboard key presses?

The frame is the same as sending commands to the SCC-32 just the commands are different.
the atom is waiting for a serial string which represents this

[WiiMoteX, WiiMoteY, WiiMoteZ, NunChukX, NunChukY, NunChukZ, JoyX, JoyY, Buttons1, Buttons2 ,Checksum]

haven’t fully digested it yet but i think you first need to send [ff] 255 in hex to indicate the start of the frame
followed by the values for the above in hex eg, [00,f1,EE …etc] then finished with [ff] to complete the frame.

In your own code you could replace WiiMoteX with left right values, wiimMoteY with up down values, etc.
The values for X,Y,Z types would be 0 to 255 with 128 as middle point and the values for buttons are 0 or 1.

No time scale for me to complete anything, suffer from to many projects at once.

Psymon

[robotdude]

@psymon

The frame is the same as sending commands to the SCC-32 just the commands are different.
the atom is waiting for a serial string which represents this

[WiiMoteX, WiiMoteY, WiiMoteZ, NunChukX, NunChukY, NunChukZ, JoyX, JoyY, Buttons1, Buttons2 ,Checksum]

haven’t fully digested it yet but i think you first need to send [ff] 255 in hex to indicate the start of the frame
followed by the values for the above in hex eg, [00,f1,EE …etc] then finished with [ff] to complete the frame.

In your own code you could replace WiiMoteX with left right values, wiimMoteY with up down values, etc.
The values for X,Y,Z types would be 0 to 255 with 128 as middle point and the values for buttons are 0 or 1.

No time scale for me to complete anything, suffer from to many projects at once.

Psymon

One minor correction here. The frame format you are referring to, 255 (sync byte), data, data, is for the SSC-32’s MiniSSC-II emulator. This method only accepts 3 bytes of data, and does not end in a 255. In fact the SSC-32 actually uses ASCII commands in it’s native language. It’s not correct to say it’s the same as the SSC-32 uses without a little clarification.

[psymon]

Thanks Jim for the clarification.
Infact that just helped work out why my code didn’t work!

Psymon

[zenta]

@Xan

Hi Zenta,

Thanks for letting me know how you measured the timing. I was thinking of buying a scoop or logic analyser. A second hand scoop is easy to get for a decent price. Logic analysers are a better measuring tool for this but its hard to get a logic analyser for a good price. But I bought myself a new (second hand) car so this has to wait for a little while

Congratz with the car!
I also bought a second hand 60 MHz scoop from a friend of mine for very little money. But I would really like to have a logic analyser too! 8)

@Xan

The new version (1.2) will have a single gait sub which covers all.

Sounds like you did it a similar way as I did too. But did you include the 12 step ripple gait too? Looking forward to see your new 1.2 code!

[kurte]

@zenta

@Xan

The new version (1.2) will have a single gait sub which covers all.

Sounds like you did it a similar way as I did too. But did you include the 12 step ripple gait too? Looking forward to see your new 1.2 code!

As I mentioned earlier I first tried the quick and dirty version to integrate his three earlier gaits. I would prefer to have them all in one as well!

I did not spend much time on it yet as I am hoping to integrate with both of your newer stuff (hint). Left on my own, I would probably try to convert all of these gait functions into one table driven function. I have not tried yet as it would probably seriously change the code and this is your code which I appreciate very much.

To make this type of changes I would probably start off changing all of the individual variables (XXGatePos(XYZ) into arrays.

Looking through your functions, I would probably generate a table of values for each step of the gait. First guess is I would make the table with one nibble per each direction(x,y,z) of each leg per step. That would give me 16 different possible things I could do to each: Nothing, set zero, +X, -X, +x/2, -x/2, +x/4, -x/4…) and see if I could reduce all of the logic down to something like this… Obviously if 16 different movements are not enough we could easily expand this…

But for now I will wait (and hope) to see your updated versions soon! (Please)

Kurt

But for now I will wait to see

[kurte]

As I mentioned on Sunday, I went ahead and made a version of this that works with the Hitec Laser 6 receiver. I have the receiver connected to IO pins p0-p5 on the BB2. This version uses the Gear up/down switch to go between walking and/or body move/rotate modes. I use the Aux switch in walk mode to choose which gait. In Body mode it switchs between move and rotate modes. The height of the body is controlled by the Left hand joystick.

The code appears to be working reasonably well. I did need to add a little deadzone to the control to keep it from wanting to walk in place. I also updated the IN/OUT code to work on the BB2 now that PS2 controller is not on the same IO pins.

For now I think I am done. I will hold off until the next versions of the official code comes out.

Kurt

[xan]

Hi All,

I’m sorry to say that the new version of the code have to wait for another week or two. I’m very busy right now and it seems like I don’t have free (read robotic) time this week. But it looks like next week will be a “normalâ€

[xan]

@Xan

Hi Jim,

@Robot Dude

@zenta

I wish the SSC32 “Q” command returned a value for how much time that was left instead of a “+”.

If Jim or Mike are reading this: Is it possible to make a movement query command that return the actual time thats left for the current move?

I’m asking Mike to look at the request. He’s actually working on the SSC-32 firmware right now anyway. He’s looking at the ONCE command.

Any news about the “Q” command? This would solve some timing issues that I’m struggling with.

Thanks,

Xan

Jim?

[xan]

Hi Kurt,

@kurte

Ok, I have made some progress. I updated the lenghts of the different joints and updated the starting point as you suggested. I have still not updated the min/max angles yet. It is starting to work reasonably now.

@zenta

Good luck! Looking forward to see a video?!

This is my first attempt of uploading a video from my digital camera, so it is not anything special, but at least it hopefully shows some progress

…

Kurt

Great work! As far as I know you’re the first one using this code on a round hex! Glad it is working!!

Sorry that I’ll keep you waiting for the new version… I’ll hope to help you out as soon as possible.

Xan

[kurte]

@Xan

Hi Kurt,
Great work! As far as I know you’re the first one using this code on a round hex! Glad it is working!!

Sorry that I’ll keep you waiting for the new version… I’ll hope to help you out as soon as possible.

Xan

Thank you. It was fun getting my Hex to work again. It has also been fun making it work using the Laser 6 receiver:

Just in case anyone with a phoenix wishes to do it, here is some of the changes I made to your code to make it work:

I added some definitions just under where you defined the PS2 defs

--------------------------------------------------------------------
;[RC Controller] 
RCch01       con P0    
RCch02       con P1       
RCch03       con P2       
RCch04    	 con P3 
RCch05		 con p4
RCch06	 	 con p5

RCpwmMAX   con 1850 
RCpwmMIN   con 1150    

I also added a new subroutine, that I call instead of your PS2Input function. It started off with some of Zenta’s earlier code:

[code];--------------------------------------------------------------------
;Read RC pulses and converts them to travellengths
;
RCInput:

pulsin RCch01,0, pwmInput01 
pwmInput01  = (pwmInput01  min RCpwmMIN) max RCpwmMAX 
if (pwmInput01 > 1490) and (pwmInput01 < 1510) then
	pwmInput01 = 1500
endif


pulsin RCch03,0, pwmInput03 
pwmInput03  = (pwmInput03  min RCpwmMIN) max RCpwmMAX    
BodyPosY = (pwmInput03 - 1300)/15    

pulsin RCch05,0, pwmInput05 
pwmInput05  = (pwmInput05  min RCpwmMIN) max RCpwmMAX    

pulsin RCch02,0, pwmInput02 
pwmInput02  = (pwmInput02  min RCpwmMIN) max RCpwmMAX    
if (pwmInput02 > 1490) and (pwmInput02 < 1510) then
	pwmInput02 = 1500
endif
;BodyRotX = -(pwmInput02 - 1500)/15

pulsin RCch04,0, pwmInput04 
pwmInput04  = (pwmInput04  min RCpwmMIN) max RCpwmMAX    
if (pwmInput04 > 1490) and (pwmInput04 < 1510) then
	pwmInput04 = 1500
endif

pulsin RCch06,0, pwmInput06
pwmInput06  = (pwmInput06  min RCpwmMIN) max RCpwmMAX    


' Depending on the position of Switch 5 we will other Move or just play with moving and rotating the body
if pwmInput05 < 1500 then
	' Standard walk
   	TravelLengthX = -(pwmInput01 - 1500)/4    
	TravelLengthZ =-(pwmInput02 - 1500)/4 
	TravelRotationY = (pwmInput04 -1500)/14 

   	' Choose gait mode by this switch.
	if pwmInput06 < 1375 then
		GaitMode = GAITMODE_RIP
	elseif pwmInput06 < 1625
		GaitMode = GAITMODE_TRI
	else		
		GaitMode = GAITMODE_QUAD
	endif
else
	if pwmInput06 < 1500 then
		BodyPosX = -(pwmInput01 - 1500)/4
		BodyPosZ = -(pwmInput02 - 1500)/8	
		
	else
		BodyRotX = (pwmInput02 - 1500)/27
		BodyRotY = (pwmInput04 - 1500)/20
		BodyRotZ = (pwmInput01 - 1500)/27
	endif	
endif
'serout s_out, i9600, "BodyPosY=", sdec BodyPosY," TLZ=", sdec TravelLengthZ," TLX=", sdec TravelLengthX," TRY=", sdec TravelRotationY, 13]    
'serout s_out, i9600, "BodyPosY=", sdec BodyPosY," BodyRotZ=", sdec BodyRotZ," BodyRotX=", sdec BodyRotX," TRY=", sdec TravelRotationY, 13]    
'serout s_out, i9600, "CH01=", sdec pwmInput01," CH02=", sdec pwmInput02," CH03=", sdec pwmInput03," CH04=", sdec pwmInput04, " CH05=", sdec pwmInput05, " CH06=", sdec pwmInput06,13]    

return
[/code]
This code could easily be tweaked some. I used the other two channels to allow me to choose the three gates and to be able to do body rotations or movement as well as walking.

I am looking forward to seeing your newer version. It would be great if we could integrate everything into one version, that maybe a few #ifdefs and a few #defines we could build it for the different versions of hexs (including different leg types) as well as for different input devices.

Kurt

[robotdude]

@Xan

@Xan

Hi Jim,

@Robot Dude

I’m asking Mike to look at the request. He’s actually working on the SSC-32 firmware right now anyway. He’s looking at the ONCE command.

Any news about the “Q” command? This would solve some timing issues that I’m struggling with.

Thanks,

Xan

Jim?

I received it today. 8) It will be uploaded early this week!