10/15/2021 at 21:11 •
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.
10/12/2021 at 17:14 •
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.
10/06/2021 at 04:00 •
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.
09/27/2021 at 19:48 •
I've created some GitHub repos for the 3d model and pcb:
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.
09/26/2021 at 21:47 •
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.
09/14/2021 at 21:25 •
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.
09/01/2021 at 17:12 •
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.
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.
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.
Crisis is averted. Project still alive and kicking.
08/12/2021 at 00:03 •
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.
08/02/2021 at 23:07 •
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.
08/02/2021 at 14:18 •
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.