Hey Johnny…!!!
Sorry for the long… wait…
Well… i’m unsure regarding that but maybe @scharette can give a hand about that.
That said, you need something for a Biped no ?
Hay Eric.
Well i find that i can convert the hex code to work for biped, but yes Biped is the end goal for this so should that be available it will save a bit of time.
I have been looking at github.com/KurtE/Arduino_Phoenix_Parts
and it seems all the files i am looking for are there but as Kurt had mentioned the RC part is only first pass and im not sure how well implemented it is as i cannot test at the moment.
With that said i am also a little confused as to which files i need. There are lots and so if you have a pointer to what ill need that would be great.
Simply looking for a standard IK Robot code that i can control with RC.
I plan to use an arduino board and SSC as i also (luckly) have one in stock so im sure i am on the right track.
But yes as i mentioned, Biped is the goal.
Hi Johnny,
Indeed, the code from Kurt seems to be well started but I am also unsure if it is in working order or which parts would require modification to complete it.
An option we discussed may be to use another interface type that you know works for sure (such as the PS2) and add to your system a secondary board that will receive the RC signals and convert them to the appropriate protocol (i.e.: emulate a PS2 adapter). That being said, this is also not trivial to do…
The main problem with RC inputs is that they are best done with support from hardware (such as hardware input capture per pin), which is not the case in the ATmega168/328.
The best at this point would be to try it out! In theory you would need one driver and one input library. The readme on this should have more info about the required parts.
Sincerely,
Ok thanks for the reply. I have had a think about things and i feel it best to stick to what is available at the moment and ill go with going back to PS2 etc.
One thing i have been searching for is the **Flowchart **that Xan drew up for a visual representation of what the code is doing. Now we are casting our minds back before Robotshop acquired Lynxmotion so if anyone can remember where that is it would be very handy.?
No it was a full flow chart of the whole operation of the code. similar to this… but had a break down of all the functions. It was about 4 or 5 years ago and possibly when v1.3 code for the hex was out.
Thanks for your help. i will keep looking.
I’m wanting to use my botboarduino and scc32u with your phoenix code to control another hex frame similar to the phoenix frame. I’ve changed the leg and body dimensions in the code to match my frame but I can tell I’m missing something else by the way the body moves up and down when it walks. Any help would be greatly appreciated.
Do you have a video?
Things you will need to change to match your hex will all be in the Hex_cfg file.
You will need to change the Min/Max angles, and Start pos for the feet also
Hello,
I am working on my first robotics project, trying to make a hexapod that can negotiate its way around obsticles. I started with a 2DoF Hexapod and using the sequencer built into the SSC-32 and Arduino pro (coded to read sensor info and output commands to the SSC-32 to move the bot), this all worked well until i looked online and saw videos of some amazing bots with heads tails and 3DoF legs… Well i got greedy and ordered an Arduino Mega, BH3 chassis and enough parts to turn my legs into 3DoF legs, so far so good. But then i could not use the SSC-32 sequencer, long story short, after a few long nights i have the phoenix code setup and configured and working great (at this point i must say ‘thank you’ to all who must have worked so hard on this code and then shared it for us all to use, awesome!). Anyway, my humble request, can anyone suggest how i can control basic movements from my object avoidance code instead of from the PS2 controller? (a way to pass the command to walk forward for example).
Kind regards
Ade
The procedure in the PS2 section sets the variable “g_InControlState.TravelLength.z” for walking forward.
What are the arguments against that you do the same?
It does not matter if this is done by the joystick of the ps2 controller or by your commando.
Thank you Napfkuchen_mit_Speck, this is exactly what i wanted to know. I apologise if i posted this in the wrong thread.
Kind regards
Ade
I’m using the Phoenix code symetrical quad arduino version on a quadrapod the is only symetrical on the z axis. Some of the legs move in an Inverted and/or mirrored manor, causing my robot not to work right at all. Also the initial leg positions are all out of wack especially the femur… my question is, what part of the code can I experiment with to fix the inverted leg movements? Some of the femurs move like it’s upside down. Also, what part of the code sets the starting positions? When I press start on the ps2 controller, some of the legs move to extreme positions. Thank you. Best regards, -Adam
Hey,
I’ll be making reference to this code available here. This link is to the most current version at the time of writing this post (hard link to that revision).
Two places you may want to look at are the files Hex_Cfg.h and phoenix_driver_ssc32.cpp.
First lets cover Hex_Cfg.h. In this file you will find many configurations about how your hexapod is set mechanically such as:
- Pins (SSC-32U channels) used for each joint
- Min/max angles of motion per joint
- Leg dimensions per joint
- Body dimensions from center
- Starting position for the feet
Second we have the phoenix_driver_ssc32.cpp. This has all the code that converts the servo positions into serial data that will be sent to the SSC-32U board.
You can search through the code for SSCSerial.print("#"); to see where the code outputs stuff to specific channels such as inside ServoDriver::OutputServoInfoForLeg. It outputs position updates to servo motors (through SSC-32U) here.
I hope this info helps.
Sincerely,
1 Like
Thankyou for the information. I am going to give it another go with the code adjustments using your suggestions. Again I appreciate the help!
Best regards,
-Adam
1 Like
I have another question regarding the initial setup of a robot. I am not sure how one would go about aligning the servos to an initial starting position. I am wondering if this is my problem. I am going to add a link to a youtube video that shows the current motion of the front two legs. What do you think? I notice that in the initial position part of the code it has several values for an initial leg position ex. cLFInitPosY CHexInitY… if this initial position code is my problem, how would one modify this… A second question I have is related to body dimensions ex. cRRCoxaAngle1 -300… what is -300? does this mean -30 degrees? And my third and final question is regarding start feet position ex #define CHexInitXZSin60 95 // sin(60) = .866… what does 95 mean? do these values affect all legs or feet, I noticed when I adjusted these values to fix one leg, it had a negative effect on the other legs. Thank you, -Adam
Hey,
I recommend you have a look at this series of posts. Kurt is the person who created the Arduino version of the Phoenix so his explanation of those settings would be a good starting point.
Sincerely,
1 Like
Thankyou I will read over your suggested thread. I am having better luck today. The code for the initial leg positon ex: cLFInitPosY CHexInitY, I am actually putting a value in there ex: cLFInitPosY -50. This is providing better individual leg positions. Thanks again for everything. -Adam
I think I may have discovered my problem after reviewing your suggested link. I need to go into lynxterm and set all servos at 1500, then adjust servo horns so that they are centered. Next use ssc-32 register offsets for fine tuning. Finally I can adjust the hexconfig file initial leg positions. I think this may do the trick.
-Adam
1 Like
Yessss! That did it. All the legs are moving in a pattern and direction that will eventually sustain walking. I will still need to make some more adjustments but I am very excited about making it this far with the robot. Thankyou again for all your help. Once I get the robot walking perfectly I will post a video. The Phoenix code is really amazing. I love how it makes the robots move so lifelike.
Best regards,
-Adam
1 Like
Yes! Centering servos is very important. Also, if they aren’t perfectly centered you can use Lynxterm to give the SSC-32U some adjustment (offset) of up to 100 µs/s in either direction (± 9°).
Cool! Looking forward to it. I recommend that you post it in a new topic, though. Maybe here or here?
1 Like