Hi all,
I’d like to show you my hexapod project. As you obviously noticed it is inspired by Zenta’s A-pod. All credit goes to Zenta as i stole most of his building ideas;). I started building it more than 2 years ago, after I saw the youtube video of the A-pod and was troughly stunned. Did get it working 2 years ago, but my lacking programming skills at that time never got it further then some basic moves and gait, back then controlled by a PS2.
I started this project 2 years ago with the main goal to learn VHDL and softcore processors (see further). And did i learn. I still use the knowledge I acquired back then every day in my daytime job.
All parts are made of hand cut clear and orange plexiglass, making it a fire–ant:-). You can see I used a different style of coxa. I tried multiple leg configurations in solidworks, I personally liked this setup more because it makes my ants body look less fat, haha;), but this is personal off course.
I picked up the project again a week ago. My increased programming skills and a new approach (using the phoenix code as a base instead of trying to make the software from scratch) already got me hudge steps further.
What might interest you is my controller approach:
I use a FPGA board (Altera cyclone3) with a softcore 32bit processor with floating point extensions, for now running at 50Mhz. The digital servos are reprogrammed to work with a bidirectional ‘onewire’ like interface over the signal wire. The PIDcontroller loops are closed on the FPGA, which contains 27 hardware PID controllers. A little arduino is mounted on top of the VHDL board. It runs a USB host for the bluetooth PS3 controller, and communicates to the softcore trough SPI (I was too lazy to port the arduino code to C for the softcore, and due to the limited memory on the FPGA I have to use external memory. It would be possible to implement the USB stack on a second softcore, but this approach was quicker.)
As you can see I made the mistake of buying cheap servo’s. I’ll never make this mistake again. The mechanics have a lot of play, and I guess my hexapod will never be smooth for this reason. Maybe in the next life I’ll buy decent servos.
The advantage of these cheap servos is that they are digital, and every one of them contains a pin PIC microcontroller. I reprogrammed all the PIC’s to have a Dallas onewire - alike interface, but at much higher speeds, 1Mhz, the maximum the poor PIC’s can follow. 9 servos connect to one of total 3 onewire busses (25 servos total). On the FPGA I have 3 onewire masters that each contain 9 PID controllers. Each servo sents its current position over onewire, the FPGA sends a new half bridge setpoint to the PIC. The 27 PID controllers and onewire interfaces are all implemented in hardware on the FPGA, unloading the processor of this task. A processor would never be able to calculate 27 PID loops and communicate at 1Mhz over 3 pins at the same time;). I forgot the loop speed, I think its about 800hz. The controller loop is actually closed on the FPGA, which allows the processor to know the current position of the servos with the servomotors not powered. This allows the hexapod to ‘learn’ the position it is set to manually, and it should be able to use a force loop instead of a position loop for the grips (not implemented yet). I’m thinking of buying decent servos and replacing the electronics by the digital boards of this servos, to have less play in the gears.
As for the inverse kinematics, the first version used a VHDL approach, calculating inverse kinematics in Hardware. This was superfast, it could calculate a full IK in less then 10 us. The downside was it used a lot of resources on the FPGA, and it was fixed point. I abandoned this approach because there was not enough high speed memory left for the softcore.
The approach now uses the 32 bit softcore to do the IK. The current fixed point phoenix code takes about 1.3ms to calculate. I have no idea how this compares to other processors? What calculation speeds do you have? I’m now porting to code to floating point, since the processor has custom instructions for floating point calculations which are in some cases faster then fixed point;). The software also controls the times moves that are generated in the SSC32. I also plan on using the CORDIC algorithm for arctan/sin… instead of lookup tables. I have not seen this being used in hexapods yet?
Still some software work to do to get the hexapod move smooth. Just finished porting and testing the phoenix code tho this platform. The IK and gait engine is already functioning correctly. Thank you Xan, Kurt and Zenta;). I just discovered the code for the lynxmotion a-pod is posted online, I used the code from Kurte’s github fornow, maybe I should take a look at the apod code:).
I hoped you enjoyed reading, look forward to hear your comments;)
Niels
