I made a brief video of my hexapod’s movement when controlled my the PS2 controller. I would very much like to see yours move in response to the same control inputs. Perhaps that will give me a better idea of what’s wrong with mine. I posted the video it to my youtube channel, here’s a link to it.
My robot moves similar to those in the links cbenson provided - perhaps not that perfect but I haven’t tried on a flat surface yet.
The first thing that strikes me when watching your video: after starting the robot, the body is much too high - it should hover 35 mm above ground. Your femurs are nearly horizontal - I doubt that this can be the result of wrong calibration. I would double-check the wiring first.
Are you using the correct software version? Afaik there are other versions configured for other hexapods. Movement parameters could be completely different. My source code is from here: https://github.com/KurtE/BBD_SSC32_PS2
This version seems to be configured for a CHR3 robot. Even if my phonix seems to move normally, I wonder if the CHR3 configuration is ok for the phoenix (which has a different geometry). But I cannot find any information about that.
You seem to be much ahead of me regarding embedded software. For the time being, I will stick to the Arduino IDE - I will try and run the Phoenix code on an Arduino Mega 2560. 256K flash memory should provide enough space for interesting libraries and own software.
In parallel, I purchased a home version of Matlab/Simulink. This is a completely different approach but it seems also possible to control Arduinos from Simulink models. They provide mighty functions but it will take some time to learn.
In both cases (own software or Simulink), I would like to use Xan’s and KurtE’s code for the movement. Thus I will have to find out how to control the movements from outside.
By the way: thanks and kudos to Xan and KurtE for their tremendous work! I hope the guys from lynxmotion know what they own you…
C. Benson, Thanks for posting those videos. If nothing else, they made clear that one thing wrong with my hexapod is that the femur servos are installed wrong (the servo horn needs to be on the bottom, and I have it on the top). Its amazing that the thing worked at all! I’ll get that straightened out and give it another run.
Arachnophobia: That is what you are seeing. The leg joints are in the wrong place, which will certainly screw up the kinematics. Easy fix, though.
C Benson, another question…When calibrating the Phoenix hexapod, should the flat on the bottom of the femur be horizontal (parallel to the ground) when all the servos are at 1500 uS? Or, should the femur be positioned as shown in the videos above and be at an angle of about 45 degrees when the servos are at mid range?
Here are some pictures explaining the Phoenix calibration: http://www.lynxmotion.com/images/html/build159.htm
However, I did not connect my PC to SSC32U but to BotBoarduino (so I don’t have to change wiring). To enable the forward mode you have to keep button A pressed while applying power to the board.
This is described as the second variant here:
It is really a pity that lynxmotion does not provide a complete set of documentation. Half of the software you need is marked as “legacy”, and you have to gather small parts of documentation from many different places. Having spent a considerable sum for a complete robot package, I should expect also a complete set of software and documentation.
After all, they sell the phoenix with this argument:
“The programming is already done for this robot. You no longer have to be a computer scientist to play with this level of robotics.”
</complain mode off>
Rather than the joint aesthetics, think that the center of the shoulder servo and that in the knee should make a horizontal line when calibrating. The tip of the foot and the center of rotation of the knee should form a vertical line.
We fully understand and do apologize for this inconvenience. We are actually working on a complete redesign of structure of user / assembly guides in a wiki format (currently private access only to staff and a number of BETA testers) which we think is a vast improvement over what is shown currently. Software redesign is also in the works. Yes, there are a good number of individuals who helped make Lynxmotion and many of its projects possible, including Kurte, Xan, Zenta, Matt D and others.
Good luck to jimlake for the final assembly!
Once your Phoenix moves smoothly I have another question. The legs of my robot collide during fast rotation. Do you have the same problem?
I am happy to report that after re-assembling the way the servos were connected, my robot now moves pretty well. As well as the one’s in the videos that C Benson has pointed out. So thanks for your observations. I hope that in the next version of the documentation, the folks at the Robot Shop include a clear close up photo of the top of the assembled robot. My mistake was caused by carelessness on my part, but a note on the photo or assembly instructions would have prevented it. Realize that in this design, the servos can be installed either way, but only one way works right.
I’ll do some more testing later today and have a answer for your question above.
I am digging into the code now with the intention of layering on an autonomous control interface. However, I notice that there are just a few bytes of memory left in the AVRMega 328 in the Botboardino. I am going to replace the Botboardino with an AVR 1284P. Its basically the same processor as the 328, but it has 128K of flash and 16KB of RAM. I notice that some folks on Git have released an Arduino compatable patch for the 1284 called the Mighty 1284P. So, the code will run on the 1284 with a bit of tweaking. Hardware wise, I’ll use a 1284 xplained board ($30 on Mouser) or I’ll make a custom pcb for the 1284P.
Either way, there should be enough horsepower in the 1284 to add a new control layer to the software that will permit things like obstacle avoidance, line following, directional control and the like.
I will also spend some time trying to understand how to use the XBEE interface to send USART commands to the software instead of the PS2 controller. Appreciate any ideas or documentation anyone might have on that.
I ran through all of the movements today. They are not bad, but the rotation does have sensitivity problem (its too sensitive to control input, much more than the other movements). I also saw the joint collisions with the rotation at high speed.
Now that’s looking a lot better! The left leg close to the receiver needs a bit of calibration it seems. One the right track and looking forward to seeing what you do.
I am having an intermittent issue with my Phoenix. He seems to develop sudden onset Parkinson’s disease without warning. I notice that when it happens the green LED on the Botboardino, which normally quick flashes, goes out and then the symptoms begin. This lasts for a bit and then disappears.
I have done all of the normal things to isolate the problem (shorts, low voltage, etc) that one would do, without success. I have also looked through the code for the routine that controls the green led (on PB3) and found only that it is defined in the main tab and turned off, but I can’t find where its turned on (or any other reference to it). So, my question, if anyone knows, is what controls the green led, and what might make it go out while the other two leds continue to flash?
To confirm (just to be certain), it’s the green LED next to the number 5 at the top of this page? http://www.lynxmotion.com/images/html/build185.htm
The green one is connected to pin8 as well as button B. Is there a chance something physically (accidentally) pushes the button (like a hanging wire, battery etc.)?
Yes, that’s the one, and no…nothing is touching it or near it. It will be working normally when without warning uncommanded spastic movements begin. Often, the led on the PS2 receiver will begin to blink (loss of signal, I think) and then he pulls in all legs and collapses. I can turn everything off and then on again but the same symptoms are present. The only thing common to all the symptoms is that green led, which goes out and stays out during the symptoms. The adjacent red and yellow leds continue to quick flash throughout. The symptoms dissappear as mysteriously as they appear. No smoke, no smell, all battery voltages OK.
I can’t seem to find what causes those three leds to flash. I see where they are declared as booleans, and I see them set to zero (off). I have searched all of the code looking for what turns them on, and I could not find it. The schematic shows them connected to a port pin. Perhaps the port is reconfigured somewhere which causes the lights to turn on briefly.