@FranklinW

The Hexapod’s CAD is DONE! Or at least V1 is finished. I integrated the PCBs into the main shell, added a battery component, put in a bunch of sensors and LEDs, and generally finished up the CAD. This is a pretty big milestone, as I can now 3D print, assemble, program, and test my creation. Over the next few days, I will be taking this guy from the screen into the real world. It’s been a journey, from initial planning, leg design and prototyping, PCB design, and finally outer shell appearance and sensor integration. The most challenging part of the mechanical CAD was making everything fit! The robot is pretty compact, and the electronics take up a ton of space. I ended up hanging the Pi from the top of the robot to get everything to fit. I think I will have enough space for wiring, but it will be close. That is the main reason why every PCB trace is overspecced, so I should, in theory, have minimal temperature rise.

Finished both PCBs and consolidated into THE STACK. This separates high power servos from my sensors. I have DuPont connectors and screw terminals to connect the two boards. I managed to fit the whole thing into the robot and align it such that the IMU is centered in the robot along both the x and y axis. That should help to simplify my data later. While the board intersects right now with the body I will fix that, so it just drops in and screws down. everything has headers and can easily be popped out if something goes wrong.

Started cooking up the PCB routing of the ‘pod. I’ve just about finished up the top board PCB. I would say this is the most complex PCB I’ve done, and Fusion free limits me to 2 layers. I’ve tried to preserve as much of the bottom layer as possible to use as a giant anti-IIC-noise ground plane. Some bottom layer traces are I believe unavoidable, just due to the size constraints (both from the ‘pod’s shell but also the fact that I don’t want to give JLCPBC like $100) that you can see in blue. Design for the robot is slowly wrapping up, there is a slight possibility initial design is completed by the end of the long weekend! Then it’s assembly and as much programming as I can fit in. If you have any name suggestions for this guy, please comment them!

Finished the schematic for the top board of the PCB. To make the best use of space, I’m splitting the board into two 80x80mm boards, stacked vertically. The top board houses all the sensor/sensor mounts, and the bottom will be purely for servo and PCAs. In an attempt to make my schematic readable, I’ve subdivided it into subareas. Because I only have time for one shot at the board, I’ve exposed pads for each extra GPIO pin on the ESP, as well as adding solder pads for the address select on the sensors. This will allow me to change the IIC address of each sensor if needed. I’ve also included 10 extra GND, 3V3, and simply “blank” header pins for future expansion. The Lidar will be handled by a chassis-mounted Raspberry Pi Zero W, which will also handle real-time IK, cycloidial calculations, and step planning (using the equations I’ve derived earlier).

Back to the CAD grind. I started making the robot body, before looking at how much time I had left and switching gears to the PCB so it can be ordered. I still have a bunch of work to do on the body, but I used a chunk of time to make some custom footprints and layouts/schematics in fusion electronics (very very annoying and finicky but i got it working). I got STEP files for the microcontrollers from grabCAD and manufacture pages, then placed my footprints around them. Note that the PCB is not how it will go together, I just put all the components down to show the footprints I’ve finished.

Made some good progress. Firstly, I finally fixed the legs. They now move in straight lines, so that the robot can move forward. Turns out I had to rotate by (or to?) 150 degrees for a -30 and 135 for a -45 (off by 180 degrees, which is interesting). I will include my best guess of what is going on, but to be completely honest, my code should not be doing that and I don’t know why it is. To figure this out, I had the very high tech strategy of taping a whiteboard marker to the leg, and tracing the path it drew in stance phase. Long story short, I have validated (on two configurations) that it works (and on the last tests I got super straight, vertical lines, as if my robot had a ruler), and have to get PCBs manufactured so it’s time to move on. I moved to the main body and housing, and got my spider design cooking up. After Fusion “lol nope”d all my loft plans, I made a very sketchy completely blue sketch and divided the loft profile into 4. It worked so I will clean it up tomorrow, then plan electronics mounts. PCB design next week, fingers crossed. Anyway, enjoy a preview of the robot running at you, and some images of a first draft for what it might look like (hopefully not too much like a cybertruck, lol)

As promised, here’s a video of the two legs working together. Interestingly, the middle leg is off by 30 degrees almost exactly, which would explain the “correct” forward legs at zero offset. I have to scour the program though, because I’m still not sure where it is coming from. As far as I know, the inverse kinematics have been working fine.

Currently trying to test a simple walk for interference. I realized when slicing a leg that my MG996R servos would have way too little torque, so I upgraded them to 40kg servos. I settled on a 375mm long robot, with the front leg on a 30 degree angle. I set up a matrix revolve function so that the robot wouldn’t push itself sideways (see very beautiful sketch). However, that revolve function did absolutely horrendous. My robot’s leg traced a ln(x) function in the x, y, and I have genuinely no idea why. Then I tried a very simple coxa offset, and that didn’t work either. I taped a pen to the robot’s leg so that I could see the path that it was walking, and found that for some reason, a zero degree offset produced a straight y (“straight”, the experiment held error). Again, I have genuinely no idea why, as the code I’ve set up should make that test path the red line in my sketch. If you see something I don’t please let me know. Anyway, I wrapped up the 10h by putting together the second leg. I’ll post another devlog shortly (hopefully) that shows (hopefully) a working step gait.

The servo “broke” :(. I started testing different step configurations to allow my robot to not hit itself while walking (kinda important). During this (and of course while I was demoing it walking), my MG996R decided to shut down. I disassembled the leg and opened up the servo, expecting a blown internal circuit, only to see nothing weird. I then tried the same (previously failed command), and it worked. I did some googling and found the culprit was likely thermal overload, and the driver/motor shut itself down so it wouldnt break. The one piece of good news is I now have an excuse to swap in a slightly refined femur backing, and that a leg swap can be completed in under 15 minutes.

It’s Alive! Did way too much math. I got the inverse kinematics fully working, allowing me to get the leg to any (z, y, z) in reach. Then I used python to generate 870 000 points it could reach and plotted a point cloud in CloudCompare. I then derived and implemented a composite cycloid trajectory to have smooth(ish) steps. By the end, I got my test leg to take its very first steps! One video shows a walk mode (there is some shake due to backlash, although I think it will be reduced with ground pressure) and the second shows “run mode”.

Finally got my robot leg V2 done in cad. going to test tonight or tomorrow when the 3d print finishes up. I wired up a test for one leg (three servos, PCA9685 and ESP32). I then coded the configuration for the robot legs, and wrote a quick servo centring program so I could assemble.