I recently bought and built a Lynxmotion Phoenix robot. I am pretty pleased with the quality of the hardware (I got the Hitec 645MG servos). I bought the Botboardio, the SSC-32U servo sequencer and a PS2 controller and interface. The hardware went together fairly easily, the software less so, but I have it calibrated and made it work…sort of.
I have noticed the following:
The Phoenix software (Xan’s) is comprehensive, complex, and very difficult follow. I am not a C++ expert, but I expected to be able to parse it out and revise it. I want to add a different style of controller and to incorporate voice capability. I have done this before in C on AVR platforms. However, I am struggling with Xan’s code.
I have also noticed that the robot doesn’t move nearly as well as some of the videos out there suggest that it does. Mine moves, but it is clumsy and lacks fluidity.
Reviewing the forum, I see that there are plenty of others who have had the same experience. It looks to me that lots of folks have built one of these, but have given up on it.
I would like to work with a group to try to resolve these problems, and get the hexapods working the way we think they should. The best way to do that is to use the existing software, but get it to work better, add gaits, and other improvements.
If there are others out there that would like to do the same, reply to this post. The first task would seem to be to put together a flow diagram of the software. Since the original authors are no longer interested, perhaps some new folks would like join me and take a stab at it.
Jim Lake
The Phoenix code uses commands sent to it from a PS2 controller. Take a look in the code to see where those commands are detected, and what each one of them does. You’d then have to replace or edit the PS2 section. It’s a question of integrating the voice recognition on the robot or somewhere else which transmits wirelessly. The voice recognition module should be stand alone and ideally be able to decipher commands and output specific commands. If the output is the word itself rather than say, a character, you can try to adapt the Phoenix code. Do you have a voice recognition module in particular you want to use or already have? Ex: https://www.robotshop.com/en/speech-recognition.html
I just assembled and finished my Phoenix with the same hardware configuration. While there are some annoying things to overcome regarding hard- and software, it is now up and running. In a first attempt, I mixed up the Servo connections (because the Phoenix was lying upside down) and had a very clumsy movement. After correcting this, it is now moving fairly well.
Are you sure your wiring is correct?
It’s a very good idea to understand, document and improve the existing code. My idea is to have the Botboarduino/SSC-32U handle all aspects of motion (if needed, also replace the Botboarduino by more capable, up-to-date hardware).
It would then be possible to add the next level: control this hardware from a Raspberry Pi, possibly via remote connection. Software (Mathworks, ROS?) could run on a PC with the possibility to debug and do fast changes.
I would then like to add sensors and try some simple things towards autonomous robots:
distance sensor
time of fligt sensor
pixy cam
radar
(for your case) speech recognition
perhaps one day even a lidar with SLAM?
So many ideas and so few time!
I cannot promise too much but I will try to understand something of the Phoenix code (I am not a C++ expert either…). I’ll post here what I find out.
My intent is to run this hexapod in the Seattle Robothon robot race next year. To do that, it needs to be autonomous. So, I have been working on software for a separate board to drive the SSC32U incorporating a simple tripod gait. The board is based on the atmel 1284P and will not use the Arduino environment. I am pretty good with hardware and competent with standard C. I have found that C works well in a micro controller context. I have resisted C++ because its not really necessary for “bare metal” applications in micro controllers. Consequently, I get bogged down with all of the classes, variadic functions, constructors, and the rest.
I will post some video of my hexapod in this thread in a day or so. Have a look at it and compare the movement to that which you experience with yours. I am sure my wiring is correct, because I can move each servo independently, and they move as instructed. I may still have some calibration issues, however.
I am also working on another separate board to give this robot (any robot) simple recorded speed capability. It is really just a small mp3 player with speech snippets recorded on external flash (4 Mb S25F132). I give it commands via UART (XBEE) and it plays the requested snippet. It also plays a set of random sequences. Its entertaining, but rather basic as speech goes. I designed and built this pcb for another project and adopted it for this one.
I look forward to seeing your hexapod movement. Maybe we can figure out why mine is a sloppy as it is. It does all of the things its supposed to. It follows the PS2 commands. I is just sloppy and awkward. I want it to be smooth and fast.
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?
