I’ve just mailed the first release (v1.0) of my onboard code to Beth. She will open a project page where you can find the last version of my code. I thought this was a good time to start a topic about my project.
As some of you may know I’ve been working on my Hexapod called BlackWido. It is almost a copy of Zenta’s Phoenix so for mechanical-design honors goto Zenta For more information you can visit the following topic: viewtopic.php?t=3763
Ok, more about my code. At first, it is still far from completed! I’ve got inverse kinematics for legs and body working. The gait isn’t included it the first version because it is far from done. (and not readable at all )
The inverse kinematics is very accurate but isn’t perfect either. The calculations are perfect and very accurate but the code needs to be optimized a lot. I want to replace the sin, cos and atan calculations with a byte table. This will improve the calculation time. I also want to replace all the floats to swords and shift the decimal number to get the same accurate but decrease memory.
You should be able to use the code on your “phoenix”. The only thing that you need to do is change the body and leg dimensions. 8)
If you have any suggestions or questions please feel free to post them!
Hi,
Excellent Xan and Beth!
I think I’ll soon have to put my Felix project on hold and move back to the Phoenix project again
I’m not an expert but most of the code seem to be very lucid. I don’t have a Wii-remote, but should there be any trouble to replace it with a PS-2 controller?
Redefining the Pin numbers for SSC32 should be no trouble, I think the standard setup is Coxa = PIN0, Femur = PIN01 and Tibia= PIN02…
If you want to use wirless, why not try my way.
Later i will release a software package. Include onboard and PC side.
For the using it and control it, I put some video into youtube as topic SFIPEXE.
If you are interesting, please let me know, I can give you more details about the hardware you need and probably how much and where to buy.
The wireless include video/audio/servo coontrol command communication. accessing by internet ip address.
Thanks for hosting the project on your web. I’m very happy with my Lynxmotion project page 8) If there are any updates I will send them to you!
Hi Zenta,
I hope that my code will be of any use for your phoenix. I didn’t looked at the wiring “Standards” when i wired everything up but I don’t think it is any problem to change those.
I don’t have a PS2 controller so I don’t have a clue of how they work but I can tell you that my PC is taking care of all the Wii Remote stuff. The only thing that I’m sending to the onboard program is some raw data in a frame and copy that to some internal variables. You can replace the “WiiInput” part by something compatible with your PS2 remote. You will need to copy the received data to the following variables:
BodyPosX, BodyPosY, BodyPosZ will move the body
BodyRotX, BodyRotY, BodyRotZ will rotate the body
RFPosX, RFPosY, RFPosZ will change the position of the corresponding feet (Right Front in this example)
Hi Tonald,
I saw you video and you’ve build yourself some interesting bot!
Currently i’m also using a wireless connection using a BlueSmirf. The first idea was to connect it directly to my Wii-remote but sadly I didn’t paid enough attention because the BlueSmirf cannot connect to a HID device. So currently I’m using my PC to convert the data received from my Wii-remote using the HID protocol to the SPP protocol that can be used with the BlueSmirf. Maybe there are some better ways to do that so I will be happy to take some look at your solution!
As you can see I fully implemented the ripple gait. As you can see I can start walking or change direction without the need for initialization. If you look closely you can see that the legs are overstretched sometimes. This happens if I’m walking on full speed and change the direction at once. I think that I can solve this by increasing the travel of a single step and speedup the servos so the max speed stays about the same.
BlackWido is still a kind of slippery on the wooden floor. I didn’t calibrated the servos since the last movie. Yep, I still hate that part I think that calibration also makes the body to be more still when walking.
It looks great! You solved the initialization very well. Awesome!! Have you been thinking more about the balance gesture ?
Not to complain Xan , you mentioned the speed, but was this at full speed?
hmm , I was thinking decreasing the travel of a single step to avoid overstretching (or am I wrong ?)
Looking forward to try your code on one of my Phoenix’s. (Right now I’m building my red Lynxmotion Phoenix with the BotBoard II + PS2 controller.
Don’t worry, i’m still planning to implement the balance calculations in my code. As a matter of fact, I already included the positions part which is turned off at the video because I didn’t had enough time to test it. I’ve got about 2 weeks to my vacation 8) so I can’t promise to work that out before I’m leaving…
I’m not running on maximum speed right now but I don’t know what the maximum speed is. My code calculates angles of the servos corresponding to the new inputs, then starts waiting for the SSC to complete the previous step. After that I’ll update the servo angles.
I could lower the time value that I’m sending to the SSC to complete the movements. On a certain point the calculations will take more time than the servos to move to the next position. I can test that now but my code needs to be optimized to get maximum calculation speed first. I hope this makes any sense…
I’m using 3 different travel lengths at the moment. One for X, one for Z and one for rotating. What I need to do is decrease the total travel distance and still keep the single travel distance. This way I can still walk maximum speed on one direction but the speed will slow down when I change more than one input at once. Haven’t got a clue how to do that though…
I’m looking forward to see another Phoenix using my code to get around! 8) Just let me know if you have any questions (or improvements). I’m planning to send Beth an update of my code as soon as possible.
Sounds great! Did you implement balance for all axis or only 2D (as I demonstrated on the video)? Yes, I understand about the time issue… , with wife, kids and work ++ I have to spend late nights (when the rest of my family are sleeping) on robots .
Yes, it make sense. Optimizing code are probably a good way to go anyway.
I’m not sure if I understand you here, but how large/small are your steps? Or what distance does the tars move between each calculation?
More calculations in one gait cycle gives you a smoother (more accurate) movement. BTW: how many steps does one gait cycle consists of? I experimented with 6 and 12 steps in a gait.
Maybe the balance gesture would make all this alot easier (or harder )?
I only in 2D and just the position without the Z rotation. I’ve just spent a few minutes on that part since I wanted to finish the gait first. I still need to figure out where I can fit in the rotation. My code works only with position inputs. If I’ve got your calculations right, I need to have a sum of the angles from each coax. Currently this is the output of my IK calculations which will be send directly to the servos. So I need to figure out if I need to do the same calculations twice or if I can find another way to work around that…
It would sure help if you could send me a example of your excel sheet. Is that possible?
My steps are between 0 and 128mm depending on the remote. But I can easy change this by divide or multiply this value. Those steps are both in X and Z so if I walk diagonal the step is about 181mm. If I change the direction at once the step will be -181mm so the leg that’s in the air will go to that position but the other legs are still in the “oldâ€
If I’ve got this right, you are doing the angle calculations twice, ones for each leg (coxa) and ones for the body. I have to take another good look at that
I know what you mean… my code often look like his programmer does on Sunday morning (PM is on his way )
Ah, again some good quality information! I know that calibrating is imported but I assumed that the travel of the servos where pretty linear. I’ve noticed in time that this isn’t what I hoped… my mistake!
So if I understand this right SEQ SSC32 does the math for the final position different for each servo? Maybe there is a way to let the SSC32 take care of that onboard. I have read something about expanding the SSC32 with some external memory so it wasn’t necessary to send the servo offsets very time. Maybe it is also possible to store the character of the servo (multiplier) so the servo will act as a perfect linear servo. I don’t know if this is possible, just thinking out loud…
I’ve got some free hours tomorrow, I think I can spent some time on calibrating and/or the balance system.
The SSC-32 V2 has registers to hold the servo offsets. It’s easy to set up and when done you no longer need to send servo offsets in your program. In fact even sending software position offsets of 0 will mess up the offsets. So comment these out when the register offsets are used.
This does not require the external eeprom to be installed. It uses the one in the atmel 168. There is no way to implement servo profiling in the SSC-32 as it is right now. Perhaps in a future update.
Even if you implement some sort of profiling scheme, I highly recommend you calibrate the SSC-32 to your servos. At least 1500uS results in perfectly centered servos. 8)
I did the calibrating for the middle position over again this weekend. I already did this when I mounted the hex the first time. I’ve noticed that even when the legs are perfectly calibrated in the middle position there is an error in position when the legs are in the “homeâ€
The SSC-32 isn’t really true open source. The code has been made available, but no one has ever submitted any modified code for the product. The original SSC-32 (mega8) limitation wasn’t in processor cycles but in code and variable space. The new mega168 version may be able to do this. I will ask Mike to get his opinion.
I have thought about playing with the SSC-32 source code, but have not yet as I do not have codevision AVR. All of my AVR C programming has been with WinAVR.
But taking a quick look at the code, I don’t think it would be very difficult to add some simple scalling to the code. You could add a command to enter the 90 and -90 degree values in the same way as Zenta did with a command like the Offset command. You would then simply need to change the convert_servo_cmd_to_pulse_arr function to use the factor to convert to the right pulse…
I found the source for the SSC-32 I think that i’m gonne play with that in time. It look like I need to include something for the servo error to get a good and precise position. But before I can experiment with that I need to replace the mega8 with the mega168. So I’m thinking of going with a fast correction in the ATOM for now and change this in a later stadium.
What’s the version of the SSC-32 included in the phoenix kit jim?
I am not sure if there is a phoenix kit yet that includes electronics? But I am pretty sure that all new SSC-32 are the new mega168s and I think they come with: 2-01XE.abl installed on them.
I decided to pay the $220 purchase the codevision C compiler, just received the confirmation email so I can unzip the files…
The AtMega168 has twice the programming space as the Atmega8 so hopefully there is still some room left. May play with programming the SSC-32. I thought it would be fun to add a command or two. Like maybe allow other IO pins to be used for inputs…
For more information you can visit the following topic: viewtopic.php?t=3763
So currently I’m using my PC to convert the data received from my Wii-remote using the HID protocol to the SPP protocol that can be used with the BlueSmirf. Maybe there are some better ways to do that so I will be happy to take some look at your solution! 
, you mentioned the speed, but was this at full speed?
, I was thinking decreasing the travel of a single step to avoid overstretching (or am I wrong ?)
.
(PM is on his way