Project Logs

Collapse

• Assembly manual

  Dejan Ristic • 06/21/2023 at 17:53 • 0 comments

  Finally got around to making a proper assembly manual for the robot.

  Manual is available on GitHub: https://github.com/dejanristic78/Tardygrade-assembly-manual.git 

  A few example pages out of the manual: 

  Initially I wanted to emulate the style and philosophy of IKEA furniture assambly manuals, where everything is explained by simple drawings. But I realized along the way that some additional text explenation were necessary.

  Page layout made in Scribus 1.5.8.

  Illustrations were made in FreeCad, using the TechDraw workbench.

  If you decide to build the robot using the manual, let me know your results.

• Parametric 3D models to fit various types of servo horns

  Dejan Ristic • 11/27/2021 at 22:20 • 0 comments

  It seems there's no agreement among hobby servo manufacturers on what exact dimensions their servo horns should be. You'd think it would be the easiest thing in the world for them to all make their horns according to an agreed upon standard, but apparently this is not possible for some reason.

  This state of things has presented me with a problem, since the two 9g servos that drives Tardygrade needs to fit their horns into precisely dimensioned slots in the 3d printed gears.

  To remedy this I made two parametric OpenSCAD scripts that lets you customize the gear parts that slots the servo horns. One simply need to take some measurements of the horn with a caliper and enter them into the script. Then the resulting stl should be a perfect fit for that particular servo horn. 

  I used FreeCad to model the the gears. These models are then imported into the OpenSCAD script, which is only responsible for making the customized cutout for the servo horn.

   Yep. Works pretty well.

• Smooth operator

  Dejan Ristic • 10/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 Ristic • 10/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 Ristic • 10/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 Ristic • 09/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 Ristic • 09/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 Ristic • 09/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 Ristic • 09/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.

  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.

  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 Ristic • 08/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:

  • AH9246-W-7
  • AH1815-W-7

  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.

View all 21 project logs