Close
0%
0%

Tardygrade

3D printed quadruped with a tiny BOM

Similar projects worth following
Tardygrade is a plucky little robot that's easy to build with components that most makers have readily at hand.

It employs an unconventional mechanism which requires only two motors, yet allows for full mobility. It walks forward and in reverse, turns left and right, and pivots 360° on the spot. It also does well on uneven terrain.

Tardygrade is designed specifically for FDL manufacture:
• The robot body is entirely 3D printed. No screws needed except for mounting the servos.
• All parts prints without support.

The Tardygrade controller PCB connects to an ESP32 dev board:
• You can use your phone to remote control Tardygrade through a web based UI.
• The PCB can be fitted with laser distance sensors, which lets the robot explore autonomously.

Everything required for building it yourself will be open sourced. See details further below.



Robot

Tardygrade is my attempt to leverage some tried and true mechanical linkages into a simple yet capable robot walker. Rather than trying to emulate gait and leg articulation from biology, I started out with a mostly clean slate.

My only two guidelines were: 

  • Minimize the number of servo motors. 
  • If possible, use only 3D printed parts.

The design philosophy has been strictly utilitarian—function over form in every case. It was only after the fact I noticed that the thing ended up being rather cute, and looking a little bit like a tardigrade.

Two peas in a pod. (Left image is creative commons, courtesy of Bob Goldstein and Vicky Madden, UNC Chapel Hill)

I've put a great deal of effort into making the robot body entirely 3D printable. Instead of screws or glue, Tardygrade relies on a combination ridges, snap fits and printer filament to keep itself together.  

All in all there are 37 printed parts. Assembly should take about half an hour.

The 3D model is being developed using Free-CAD and OpenSCAD.

Controller

Automation control is based around the ESP32 µC. I'm designing a 5x5 cm printed PCB that acts as a shield for an ESP32 dev-board. The PCB has two pairs of pin headers, for compatibility with both the "Adafruit HUZZAH32 Feather" and the "Tinypico" form factors.

The shield has three main functions:

  • Allows the ESP32 to perform motion control via four hall sensors, which detects the position of a magnet mounted inside the main gear.
  • Voltage regulation for the servo motors.
  • Hardware interface to laser distance sensors.

I'm also planning to add a downward-facing rgb led, to illuminate the robot body from within. There's no practical utility in doing that. I just think it would look cool.

I'm designing the PCB using KiCad EDA. Prototype boards were made by Aisler.

My first attempt at a printed PCB, complete with botch wires. The shield on the right is rocking the excellent Tinypico dev-board.

Software

The automation software is being written in MicroPython. 

For web server on the ESP32 I use Microdot. User interface is written mainly in JavaScript, for remote control via a phone web browser. In addition, the web server provides HTTP endpoints for accessing all automation functions. 

I will probably add some simple AI boilerplate that lets a Tardygrade fitted with distance sensors walk about autonomously. The boilerplate code can then be extended by users who want to experiment with their own AI code.

At some point I might start working on an Arduino port as well.

"Steering wheel" prototype for the web UI. Controls for direction and speed.

Open source

For those who are interested in building this robot themselves, all relevant files will eventually be open sourced. This includes:

Bill of materialshttps://github.com/dejanristic78/Tardygrade-BOM
3D CAD model (FreeCad)https://github.com/dejanristic78/Tardygrade-3d-model
3D printing files (.stl format)https://github.com/dejanristic78/Tardygrade_stl_files
PCB cad model (KiCad)https://github.com/dejanristic78/Tardygrade-pcb
Firmware source codeWorking on it
Assembly manualWorking on it

Please beware that the robot is still being developed and is not yet production ready. If you would like to build it right away, and perhaps provide me with feedback while doing so, you are welcome to join the Tardygrade Discord server. 
PM me for details.

Tardygrade will probably also show up as a kit on Tindie at some point, if I can figure out a way of doing international shipping that doesn't cost more than the thing itself. 

In that case people will have the option to get just the shield PCB and print the robot themselves. Or get the full kit if they don't have access to a 3D printer. The prints I'll offer on Tindie will use some higher quality materials like carbon fiber infused nylon, and maybe flexible filament for the legs.

Portable Network Graphics (PNG) - 220.10 kB - 07/05/2021 at 16:25

Preview
Download

Portable Network Graphics (PNG) - 248.86 kB - 07/05/2021 at 16:25

Preview
Download

Portable Network Graphics (PNG) - 42.75 kB - 07/05/2021 at 16:25

Preview
Download

Portable Network Graphics (PNG) - 39.14 kB - 07/05/2021 at 16:28

Preview
Download

Portable Network Graphics (PNG) - 58.35 kB - 07/05/2021 at 16:28

Preview
Download

View all 7 files

  • Smooth operator

    Dejan Ristic10/15/2021 at 21:11 0 comments

    Improved servo action using the esp32 remote control module (and a tiny bit of math)

    The Tardygrade turning gear mechanism is designed to allow the robot to pivot 15° at each step. In theory this will let it pivot a full 360° within twelve full revolutions of the main gear.

    But there's a snag. The servo moves at linear speed, resulting in abrupt acceleration and deceleration. This can make the feet loose their grip and slide about, which means pivoting the robot to a precise degree becomes impossible.

    After becoming aware of this issue I made a brief attempt to introduce smooth endpoints to the servo action. But since I couldn't immediately figure out how to put that into code I threw it in my mental basket marked "annoying little bugs I'll probably get around to fix sometime".

    Now I figured would be a good time to pick something out of that basket instead of putting more stuff in.

    I had bookmarked [James Brutons] video on how to make robots move smoothly (which I probably found on the Hackaday blog originally).
    Although the method he used was elegant, it only provided smooth deceleration. I needed smooth acceleration as well. 
    The comment section steered me in the direction of cosine interpolation—thanks YouTube user [Cole Smith]. Then this post on the CodePlea blog "refreshed my memory" on how to do it, and also covered an alternative that doesn't involve cosine.

    in the end the math required was as simple as: x^2(3-2x)

    Now, all of this worked well enough when using the machine.PWM library. However there's some considerable loss of duty cycle resolution since that library only deals with integers.

    But by being a frequent lurker on the micropython.org forum I'd been made aware of an alternative, thanks to user [wangshujun].
    The ESP32 RMT module is intended for IR remote control communication, but can really be used for any kind of pulsed data. It's accesseded through the esp32.RMT library.

    Using RMT instead of the PWM library brings two advantages: One is higher duty cycle resolution. The second is that the entire pulse sequence can be offloaded to hardware, which is an ideal way of making the servo action non-blocking. This will allow the robot to be more responsive when controlled by remote. It can also make life simpler when adding new functionality like AI and such.

    While I was at it I saw no reason why not to use the RMT module to control the other servo as well. While not as dramatic of an improvement, that allows me to easily achieve gradual changes in walking speed, which is a nice feature to have.

  • Bugfixes for PCB v0.3

    Dejan Ristic10/12/2021 at 17:14 0 comments

    I've meandered through a few weeks of low activity, but I finally had time to track down the bugs that arose when I tested out my most recent PCB revision. 

    First bug was the power switch MOSFETs that didn't seem to work as expected. 

    That turned out to simply be caused by a coding error. When I shuffled around the GPIO pins there was a stray line of code left that gave rise to some hard to diagnose problems.

    The second bug was specific to the Adafruit HUZZAH32 dev-board. Two of the hall switches didn't trigger as expected like they would when using the TinyPICO dev-board.  

    This was due to me not reading the datasheet closely enough. To save on external components I use the ESP32 internal GPIO pull-ups to hold the output of the hall switches high. But it just so happened that those two particular GPIO pins didn't have any pull-ups. That was a face-palm for sure. Actually both of these issues were very avoidable.

    No matter. I've updated the pcb design and sent it off to fabrication today. Expect to get the boards end of next week.

    In the meantime there are plenty of loose ends to tie up in other areas of the project.

  • Showcasing the new prototyping shield

    Dejan Ristic10/06/2021 at 04:00 0 comments

    The Tardygrade prototyping shield is a general purpose perfboard pcb that fits on top of the robot and breaks out the unused GPIO pins of the ESP32.

    Here I have utilized it to build a little solenoid drum machine that adjusts its tempo to the walking pace of the robot.

  • Tardygrade is now on GitHub & Discord

    Dejan Ristic09/27/2021 at 19:48 0 comments

    I've created some GitHub repos for the 3d model and pcb:

    https://github.com/dejanristic78/Tardygrade-BOM

    https://github.com/dejanristic78/Tardygrade-pcb

    https://github.com/dejanristic78/Tardygrade-3d-model

    https://github.com/dejanristic78/Tardygrade_stl_files

    Firmware repo is on my to-do list.

    I will include the appropriate open source license when the project nears completion. For now, anyone can download and experiment with these files for personal use.

    Please beware that the robot is still being developed and is not yet production ready. If you would like to build it yourself, and perhaps provide me with feedback while doing so, you are welcome to join the Tardygrade Discord server. PM me for details.

  • New pcb test run

    Dejan Ristic09/26/2021 at 21:47 0 comments

    The new controller pcb has passed the walking test. Hooray!

    However there seems to be a weird issue with the power supply MOSFET:s. I will devote a later post to it when I've had time to investigate. 

  • New PCB & prototyping shield

    Dejan Ristic09/14/2021 at 21:25 0 comments

    Here's the new v0.3 pcb design. Layout has been adjusted to accommodate the change to AH1815-W-7 hall switches.

    Since the hall switches needed to be placed on a smaller radius I had to rotate the esp32 board headers by 45°.
    Hand soldering the board will be a bit more difficult since everything is a bit more cramped. But overall I'm satisfied with this layout.

    New for this iteration is an expansion shield that fits on top of the controller PCB. It's a through-hole prototyping board that breaks out the unused GPIO from the esp32 board. I also threw in some smd footprints for good measure.

  • Switching switches

    Dejan Ristic09/01/2021 at 17:12 0 comments

    Quick recap

    The global chip shortage snatched away the "ultra high sensitivity" hall switch I was planning on using for the Tardygrade controller pcb. So now I need to make do with a non-ultra alternative. 

    What the consequences are

    Due to the lower sensitivity of the new IC I needed to move the magnet in the main gear closer to the controller pcb in order for it to be detected. The old design had the magnet embedded inside the body of the gear, which allowed me to place it at any angle with respect to the cams. This allowed me to layout the pcb as I pleased, since the magnet position could be adjusted to fit the layout of the hall switches.

    The only way to get the magnet closer to the pcb is to slot it into the upper cam. But that also means I'm committing to a specific radial placement of the magnet, which leaves me with only one way of placing the hall switches.

    New position of the magnet.
    New position of the hall switches. Layout of the pin headers and all other components will need to change as a consequence.

    What to do about it

    For the next pcb prototype I'll turn the pin headers for the ESP32 board to a 45° slant in order to make room for the hall switches. But before ordering new boards I wanted to test the whole concept in practice by retrofitting one of my current prototype boards. 

    With the use of hot glue and some tricky soldering I transplanted the hall switches to coincide with the new magnet path. I then mounted the pcb at a diagonal to simulate the new hall switch placement.

    Shoddy as hell.

    The result

    I'm happy to report that this setup worked out well in testing. The magnet was being detected consistently, which was the main thing I was worried about. Accuracy seems to be as good as before or perhaps even a bit better. Maybe that has to do with the "edge" of the magnet field being less diffuse at a shorter distance, but that's just my speculation.

    In conclusion 

    Crisis is averted. Project still alive and kicking.

  • I didn't think it would happen to me

    Dejan Ristic08/12/2021 at 00:03 0 comments

    I'm now officially a victim of the component drought of 2021. But I will persevere.

    The PCB for Tardygrade is as simple as can be. The most exotic components on it are four surface mounted hall switches. They detect the position of a magnet embedded in the main gear, which lets the uC know the position of the robots legs. 

    When designing the first PCB prototype I had whittled the choice of hall switches down to two options:

    These were both hand solderable and not too expensive when bought i bulk. Since the magnet is fairly far away from the sensors (almost 9 mm) I went with AH9246, which is branded as having "ultra high sensitivity".

    Two weeks later I received the PCBs and after having added some botch wires everything ended up working as expected.

    I then started working on a new improved PCB. I browsed Mouser for components, and noticed that the stock of AH9246 was down to 3000. 

    Didn't there use to be around 8000 last time I checked? And factory lead time was 18 weeks. Hmm, better stock up before they run out. 

    Naah, I'll do it tomorrow. 

    Next day it was down to 0.

    I checked on my second option AH1815. They were running low too so I cleared out Mousers remaining stock of about 1000 units. They were a bit cheaper anyway and required fewer external components. But at this point I had somehow forgotten all about the difference in sensitivity and just assumed that the AH1815 would work as a drop in replacement for AH9246.

    Well, turned out it didn't. The AH1815 wasn't even close to detecting the magnet at that distance. And at the time of writing factory lead time for the AH9246 is almost a year ( ! )

    But I think the situation can be salvaged with a minor redesign of the main gear and PCB.

    Instead of being embedded inside the gear body, the magnet will be slotted into the upper cam of the gear. This puts it right up against the ceiling of the chassis, and much closer to the hall switches. Seemingly close enough for the magnet to get detected.

    There's and issue with that solution however: 

    With the old magnet placement the hall switches could be placed along the front, rear, left and right edges of the board. But a magnet placed in the cam will be at a diagonal of the board for each of the four relevant leg poses. This, in combination with the fact that the magnet now traces a smaller circle, means that the hall switches would overlap the uC pin headers, using the current layout.

    So what I may need to do is to rotate the headers for the uC boards, to make just enough room to fit the four hall switches on the bottom of the PCB.

    Well, it's not the worst thing in the world. Might even look cool. And at least I'm now stocked up with hall switches for the foreseeable future.

  • Misadventures in warp zone

    Dejan Ristic08/02/2021 at 23:07 0 comments

    I'm planning to do some automated endurance testing of Tardygrade later in August. I want to find out if it can whitstand a few hundred hours of movement without breaking down. I'm actually more worried about the drive servo than the 3D printed mechanism, but it remains to be seen which will buckle first.

    I think PETG is a reasonable material choice for the 3D printed gears. It's quite tough and will probably not wear down easily. That being said, nylon would be even better. So I decided to try it.

    I used Filamentum nylon FX256 for the tests. Not sure what is different in that formulation compared with other nylons, it's simply the one I happened to have at hand.

    The small drive gear printed fine in nylon without any warping. But the main gear was another story. Most of the gear teeth would loose grip and start warping halfway through the print. I switched to a glass bed with glue stick but still got similar results. I also tried a range of different extrusion- and heat bed temperatures to no avail. 

    The thing was that the smaller drive gear printed with no issues despite having identical teeth. Could main gears tendency to warp have to do with its larger area? 

    I decided to test that theory by modifying the gear by cutting ditches all through the gear. The idea was to avoid having a big slab of material in the center pulling on the the perimeter, and thus avoid warping.

    The experiment wasn't as successful as I had hoped, if at all. Although there were fewer warped teeth on the modified gear, I only printed one so it might have been a fluke. Either way the warping was not eliminated.

    A straight PETG gear is much preferable over a warped nylon gear. But I might still give nylon another go in future.

  • Carbon copy

    Dejan Ristic08/02/2021 at 14:18 0 comments

    While waiting for the new Tardygrade PCB to get shipped from Germany I passed the time by trying out some more exotic filaments for the chassis.

    I had wanted to try using nylon CF (carbon fiber) filament. This makes for very strong parts. And they also come out considerably lighter than ones printed in PLA or PETG. Both of these properties are of course desirable. The drawback with nylon however is its tendency to warp.

    Luckily Nylon CF doesn't seem to warp as much as regular nylon, but still it does warp noticeably even after getting printed perfectly flat on a glass bed.

    Because of this I decided to alternate nylon and PETG parts in a layer cake fashion. Once assembled, the nylon parts gets more or less bent back into shape due to the rigidity of the PETG parts. I used nylon CF for the floor-facing parts with thin walls. This should make the robot tougher and more resistant to fall damage. Also the material looks very nice with its matte finish and almost invisible layer lines.

    Initial prints had quite a bit of stringing. With other materials that's pretty easy to clean up. But with nylon CF I found the stringing tends to form shaggy carpets that are very tough and resistant to knife blades, especially inside corners. Since I rely on tight tolerances this stuff would seriously interfere with the mechanism.

    After a few more tries I managed to get rid of almost all of the stringing by enabling the "Avoid crossing perimeters" option in PrusaSlicer and bumping up the retraction to 4 mm. I wouldn't generally recommend that much retraction since it can mess up the extruder on some printers, but my Prusa I3 seemed to be able to handle it.

    I also lowered the extrusion rate to 95% which resulted in a smoother surface finish in my case.

    The other problem was the abrasiveness of the material. To avoid friction I shaved 0.5 mm off the main hull floor to make sure neither the main gear nor the drive gear would come in contact with it. 

    I then added a little washer for the drive gear to rest on. It's made to have circular layer lines and can be printed separately with a low friction filament (in this case nylon FX256).

    The main gear only makes contact with the eight little protrusions around the well leading down to the bottom actuator. 

    The steering gear doesn't move nearly as much as the two other ones, so I think a little bit of friction is ok in that case.

    The leg parts were printed in black nylon FX256. Nylon is of course especially suitable for the snap fit parts. They were much easier to unsnap once inserted and should withstand many more cycles than ones made with PLA.

    Next I want to try and print the legs with flexible filament. I'm waiting for two spools of TPU that should arrive next week. Let's see how that goes. 

View all 19 project logs

Enjoy this project?

Share

Discussions

Mike Rigsby wrote 10/08/2021 at 00:46 point

Congratulations on being a winner in the robots challenge--great project!

  Are you sure? yes | no

Dejan Ristic wrote 10/09/2021 at 11:04 point

Thanks!

:-)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

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