Close
0%
0%

<n>pod, controller board and simulator

Golang hexapod simulator and controller.

Similar projects worth following
A couple of years ago, I built this Dynamixel powered Hexapod. It sports 18 AX-12A servos and a custom controller board of my own design. It looks impressive, but it lacks proper kinematics firmware.

I have to admit that I underestimated the complexity of robotics at the time of the build. Building a robot is easy. Making it behave the way you want is a bit more difficult.

In order to properly learn the fundamentals of kinematics for this system, I decided to create a simple pod simulator in golang. This allows me to play around with topology, forward and inverse kinematics, various gaits and gait transitions.

I'm currently running the simulator under Windows and MacOS, but I am planning to also compile it for Raspberry Pi, which I in turn can use as a more generic robot controller (Or maybe just run the kinematics part on a computer and then stream servo parameters to an ESP32 based controller board)

Originally, I was aiming for a pure hexapod simulator, but as the code matured, I realized that it was trivial to add support for pods with a different number of legs. (e.g. pentapods, heptapods and octopods etc). Since the kinematics is generic, adding support for other pods turned out to be trivial, but the choice of gait patterns are restricted for certain N number and legs. (Hexapods can choose between tripod, wave and ripple gaits, but trying to implement something other than wave gait for a heptapod made my head hurt)

I chose golang, since the language compiles on both mac, windows and raspberry pi. The idea was to first run the simulator with the GUI to verify the kinematics on a computer, and then run more or less the same code in "controller" mode on a raspberry pi (as a controller board for the robot).

Another possibility is to run the controller/kinematics code on a computer and then stream the servo parameters to a simpler ESP32 based board over the network. This also enables easy integration with external sensors in the room, as well as making it possible to orchestrate the movements of several robots at the same time.

As soon as the project is finished, i.e. I have wandering hexapods in the mancave, I'll opensource the code and design files on github.

View all 6 components

  • May 5. Update - Dynamixel Espressif Driver

    Hans Jørgen Grimstad13 小時前 0 comments

  • May 3. Update - dynamixel2espressif

    Hans Jørgen Grimstad2 天前 0 comments

    I pushed my first component to the Espressif repository today. Yay ! :)

    Robotis has a Dynamixel SDK for linux, mac and PC along with an Arduino library (Dynamixel2Arduino). Since I don't want to run the arduino framework, but instead use espressif / FreeRTOS, there was a bit of "impedance" mismatch between available libraries and the toolchain.

    The Dynamixel2Arduino is available under Apache 2.0, so I downloaded that, did some minor tweaks (since the c++ compiler in my toolchain seem to be somewhat stricter than the Arduino IDE) and implemented a new version of the port handler class (which is responsible for chatting with the UART).

    Except for the DXL constructor the API is unchanged.

    I have only done rudimentary testing so far (ping, set position etc), but the espressif port seems to be well behaved.

    I have made the espressif version available on the ESP Registry (ESP Component Registry) and on GitHub.

  • May 1. Update

    Hans Jørgen Grimstad4 天前 0 comments

    While waiting for JLC PCB to send me the new boards, I had to dismantle another robot and continue testing on one of my older boards.

    Today's task was to "port" the Dynamixel2Arduino-library to espressif / FreeRTOS (I have had a peek at the Dynamixel SDK and also the Dynamixel2Arduino library, but wasn't able to find an official library for espressif / FreeRTOS). So far this has been relatively trivial task with relatively minor changes to make it compile and run.

    The API + semantics are identical, execpt for initialization of the DXL class which is now:

    Dynamixel2Arduino dxl(UART_NUM_2, DXL_DIR_PIN);

     (I guess 'll rename it to Dynamxiel2Espressif when I'm done :))

    I have to do more rigid testing before I can claim success, but initial results are promising.

    One benefit of having this run under espressif / freertos is that it allows me to also use the dual core S3 and pin the driver to one core, while the UDP server runs on the other core. Not sure if this is really necessary, but it might be useful if the ESP gets really busy (The XL-320 servos can be configured to respond with status packets anywhere from 0 to 508 microseconds after it has received an instruction packet, so the latency requirements can be pretty tight if the controller wants status info from the servos to be able to operate).


  • Apr 30 update - smokin'

    Hans Jørgen Grimstad5 天前 0 comments

    This is a little annoying, but I had to spin another revision of the PCB since the CP2102N chip overheated and self-destructed after about half a day of testing Oddly enough, this did not happen immediately. I initially suspected that I had a short on the PCB, but after having smoked the board a second time after having replaced the CP2102N I suspected that there was a brain fart in the design.

    I have previously used the CP2103 in other designs and I had the USB VBUS connected directly to the VBUS pin on the chip. Unfortunately, I had not read the data sheet on the CP2102N well enough. It turns out that the VBUS has to be connected to the USB_VBUS via a resistor ladder. I have now updated the design without changing the rest of the layout (, so I don't have to order a new PCB stencil in addition.)

    In other news:
    The Golang dynamixel driver seems rather unstable and tends to lock up in certain scenarios, so I have now abandoned the plan to stream native DXL2.0 packets over UDP to the board and I plan to instead stream servo angles over UDP and then port the Arduino2Dynamixel driver to espressif/FreeRTOS and let that handle the servos. This wil also make it possible to handle status packets from the servos with a reasonable latency.

  • Apr 21 Update

    Hans Jørgen Grimstad04/24/2024 at 10:41 0 comments

  • Apr 7 Update

    Hans Jørgen Grimstad04/24/2024 at 10:40 0 comments

View all 6 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates