I'm designing a 3D printable quadruped which only uses two servo motors. One servo for moving forward and the other one for steering.
Want it to be easy to build and control. Also maneuverable and able to clear minor obstacles and uneven terrain.
I've previously tried building a couple of two-wheeled robots with the intent of having them drive around my apartment unattended. However that hasn't usually worked out as well as I'd hoped. What tend to happen is that the robot gets stuck on something after a minute or two, and I'll have to go rescue it. Usually the stumbling blocks are obstacles that aren't easily detected by sensors: carpet edges, door thresholds or wires.
I want to design a quad walker robot platform that is really simple to build and is suitable for negotiating living room floor terrain.
Once I've arrived at a design I'm satisfied with I will publish stl files for 3D printing, buid instructions and code examples.
Very little progress with the project for the last few months. Have some ideas on how to improve on the last prototype, but been too busy with work to finalize a new design.
I've kept on noodling around in Tinkecad. But as the model has gotten more complex I've concluded that Tinkercad isn't the right tool for the job anymore. When I want to change one aspect of the model, several other parts are affected and it cascades into hours of labour.
Since I'm planning to make a major overhaul of the design anyway, I've decided to remake the model from scratch, this time using OpenSCAD.
There will be an initial time investment in doing so. But ultimately it will be easier to try out different design ideas using parametric CAD modeling. The idea is to only need adjusting som key parameters, and all the dependent measurements will get adjusted automatically. Well that's the plan anyway.
Just a short post for now. Project is still alive. Expecting to get the OpenSCAD model done some time in January.
In my last post I pointed to the RPi as the reason why I couldn't get the same smooth servo action as with the previous prototype.
It's a poor carpenter who blames his tools.
Today I went back and looked at the code and it turns out the real culprit was my shoddy middle-of-the-night programming. I've fixed the Python script and now the stutter is gone and everything runs much smoother. I also fixed a bug in the turning sequence which made the turning radius much wider than it needed to be.
This time around LB-312 struggles a bit when walking in reverse. That seems to be a mechanical problem. I tried to add some lithium grease to the gears but that didn't seem to improve things. A possible cause is that the load is unbalanced.
The project has pretty much been on hold since March, but last week I finally found some time to finalize this new prototype. This time around Landbeest is going IoT with an onboard Raspberry Pi Zero. I can ssh into it and call Python functions for different movement sequences. Here's the video:
The plan is to eventually put the 3d model up on Thingiverse. To that end I've mainly focused on making the model sturdier and easier to print and assemble. There's no longer any need for gluing parts together—all pieces are now either snap-fit or uses screws. I've also put little notches on the sides of snap-fit parts that indicates what they should attach to. (I tend to forget that myself.)
.On earlier prototypes I hadn't attempted to make the robot selfcontained with onboard battery and electronics. I just used a wire harness with an Arduino Uno for controlling it. Making this prototype teatherless was pretty much an afterthought. I just hotglued a PCB with the RPi and servo drive components to one side. The PCB holds a little leaf switch (top right in next image) that lets the RPi know when the drive gear has completed a revolution.
I found running Python on RPi to be a bit less responsive than an Arduino when trying to stop the servo in response to the switch closing. So with each revolution the mechanism stutters a bit in order to find its proper position.
Below the PCB has been connected with the RPi and power supply cable for the servos.
I should really start thinking about modifying the design to have a proper platform for fitting electronics onto. There's basically two options:
The battery currently attaches to the pivot on the bots undercarriage. If the legs where a bit taller I could fit a larger container on that spot for housing all of the electronics. Sort of like the gondola on an airship.
The other option is to have a detachable platform hovering on top of the robot.
I like the gondola option best, except the legs would interfere with any distance sensor you might want to fit there. I'll need to think it through before deciding which way to go.
I've now built the LB-302 prototype, which implements the scissor steering method I described in my last log. It was actually only supposed to be a throw-away draft—I basically had no expectation for it to work on first try. But it turned out to work great. Go figure!
This won't be a long post. Mainly I want to show this video of LB-302 in action:
This shade of blue looks pretty awful on camera. I had planned to print the actual demo version parts with contrasting colors in order to showcase the mechanism better. Here's an image of the main components for some more clarity:
The reduction gear is based on these parameterized gears made by Leemon Baird.
I was happy to discover that LB-302 can achieve a tight turning radius with no problem. And it also has the ability to pivot 360° on the spot.
LB-302 only uses two servos. But I did have to cheat and add a cherry switch to the component list. It's necessary in order to monitor the legs position, since they're driven by a continuous 360° servo which lacks position control. The requirement to keep track of feedback from the switch also makes the Arduino code a bit more complex than I'd like it to be.
Overall though I'm quite pleased with how this prototype turned out. Obviously it's not polished and not very practically useful. For one thing there's not much room for fitting a pcb and batteries onto the chassis. But I finally have a practical solution for steering, so I still feel I've made some real progress with this one.
I'll probably do a more elaborate writeup on this later, along with a better looking prototype.
On a final note I'd just like to mention that my project placed as one of seven "runners-up" in the Hackaday 3D printed gears challenge. Sweet! Thank you judges! Now I'll head over to Tindie and try to decide what to spend my $100 voucher on.
I'm quite happy with how the 1-servo drive train turned out on the LB-201 prototype. I think it has potential and is the right way to go, even if it needs some more work. Then the main design issue remaining is deciding on what method should be used for steering.
I've previously tried out articulated steering with the LB-101 prototype. As expected, that prototype barely worked at all. As I see it, effective articulated steering using only 3D printed parts will be difficult to achieve even with a more carefully worked out design.
In this log I'll present an idea for a different steering method. I'm calling it "scissor steering" for lack of a better term.
On the LB-201 prototype the cam axle is mounted horizontally between two pillars.
But when using this steering method, the cam axle needs to be mounted vertically instead. In the image below the vertical cam axle is represented by the red circle. The bottom end of the cam axle is mounted through a hole in the chassis, and its top end is connected to a 360° servo. It drives two yokes, represented by purple and blue arrows, each of which moves a diagonal pair of legs. Of course the yokes must now be horizontally oriented, not vertical like on LB-201.
Now let's forget about the cam and yokes for a second.
In the next image I've divided the chassis into two parts: green and cyan. They are connected by a pivot (the gray circle) which allows them to move like scissors. Let's also imagine that there are some gears around the pivot on the green part of the chassis, which is turned by a geared servo mounted to the cyan part.
Now let's put the cam axle and yokes back into the picture.
In the figure series below the bottom end of the cam axle is mounted through a hole in the center of the pivot. Each yoke drives the two diagonal legs of its respective chassis part.
A right turn is executed through repetition of the following two steps:
In the center figure, only the blue legs are touching ground. The cyan chassis part pivots clockwise.
In the right figure, only the purple legs are touching ground. Now the green chassis part pivots clockwise by the same degree.
I believe this method should work both for rotating Landbeest while at a standstill, as well as for making a turn while walking.
The purple and blue yokes are basically only connected to their respective two legs. Consequently, as the cyan chassis part pivots clockwise (center figure) the purple yoke will pivot with it. This is allowed, since the cam axle rotates on a vertical axis. However the synchronization between the yokes will get somewhat messed up until the green part has executed its pivot (right figure). But I don't think that will be a big deal as long as the pivot angle doesn't get too large.
It will probably be a while until I can fully put this idea to practice. The last prototypes I've made has incrementally improved on previous stuff, but this one will be more of a reboot. I'll probably make at least one intermediary prototype before I attempt a fully realized one.
I think this is a pretty neat idea, but implementing it is a whole other story. There will be bunch of practical issues cropping up once I start dealing with the reality of this thing.
I've now built and tested the LB-201 prototype, which uses the 1-servo drive mechanism I worked on last week. There's no steering on this one. I'll deal with that issue that later.
Here's LB-201 trying to climb over a few different obstacles:
The servo, when at full speed, is really giving the robot a full body workout. That doesn't necessarily translate to better performance though, since the legs tends to loose grip at that speed. I'll probably want to add a reduction gear to future prototypes.
Cam axle orientation
The cam axle is mounted horizontally, which definitely gives this robot something of a steampunk aesthetic. That wasn't something I was striving for though. It just happens to be the simplest arrangement I could think of for coupling the yoke movement to the legs. The obvious flaw with this design is that since the load is off-center it's hard to avoid mechanical friction as the cams moves through the upper range of the yokes.
The perhaps more sensible design choice would be to have the whole assembly turned by 90° so that the side of the yokes are on the same plane as the chassis. In addition to lower risk of friction this would also make the robot less top heavy.
I didn't want to dismiss the horizontal cam axle arrangement without giving it a shot first, since it has the advantage of requiring less intricate 3D printing. But unsurprisingly it proved to have problems with friction which I'm not sure can be remedied merely by refining the design.
The terrain-going capabilities of LB-201 have been somewhat improved compared to previous prototypes. The linear actuators previously had a travel of 2 cm, which allowed the legs to lift about 1 cm above ground. The cams on LB-201 turns along a 3 cm radius, which also gives the actuators a travel of 3 cm. This means LB-201 can clear obstacles of about 1.5 cm. It's a start, but 2 cm or more would be even better. That's a challenge for another day though.
I'm still using Tinkercad exclusively for this design. But now that the number of moving parts has increased I'm definitely getting to the point where it's a real chore to get all the measurements right. I should probably start thinking about migrating the project to OpenSCAD at some point.
I originally planned to have another go at articulated steering as my next project endeavor. But I've recently figured out another method of steering which I think it might have more potential. If I don't find any holes in it I'll lay it all out in my next log post.
Finally, here are some pictures of the printed parts and how they were assembled:
This is a quick update on my progress with the 1-servo drive train.
Earlier this week I finally managed to get a grasp on how to to construct an elegant mechanism for driving all four legs with just one servo. I've since realized that while I had the basic idea right, I was a bit off on the details.
I've now thought it through and modified my solution. To convince myself that it actually works I printed this mechanical model:
The jig transfers rotary motion to the linear actuators in order to cycle through the four leg poses discussed in previous logs. The actuators takes turns moving while the other one is stationary. Turning the wheel in the opposite direction will cycle the poses in reverse which will be used for walking the robot backwards.
The whole thing looks pretty simple once it's there in front of you. But I'm not ashamed to say that I find this mechanical stuff a bit challenging to visualize and as a result I've had a few "what was I thinking"-moments before I got this to work.
Another thing that had me stumped initially was how wide to make each dwell of the yoke, in order to have the actuator pause exactly half of the time. Turns out that's not rocket science either—I believe the right answer is one third of the wheel diameter minus half the cam diameter. EDIT: I think that should read "one fourth of the wheel diameter minus half the cam diameter". But don't take my word for that either.
The main thing that might need improvement is how the cam that moves the top actuator is tacked onto the bottom actuators cam:
That looks a bit fragile doesn't it? I think a better solution would be to have one cam on each side of the wheel. But with the current design the yoke isn't wide enough and would bump up against the wheel axle. However if I were to use substantially wider cams I might be able to use that solution (since that would also make the yoke wider). Such a design would be more compact and also less prone to break. EDIT: The yoke will hit the axle regardless of cam diameter. But it's still a good idea to make the cam thicker for added strength.
Now it's time to leverage this amazing new tech with the next Landbeest prototype (LB-201). I hope to have it up and running within the next few days.
I've now built and tested the LB-101 prototype. I spent very little time on this one, and took a lot of design shortcuts.
Mainly I wanted a practical test of turning by means of articulated steering. I also wanted to find out if this steering method is feasible using only 3D printed parts.
I figured that if this very rough draft could manage to turn left and right without immediately breaking down, then there might be some merit to this this type of solution. I'd hate to have spent weeks on a solution that ends up being a dead-end when finally put to the test.
My hopes started waning during assembly and I sort of suspected whole thing would tear itself apart immediately. So I was somewhat surprised it actually worked as well as it did.
Here's LB-101 executing left turns at 15 and then 30 degrees:
The 15° turn performed fairly well, but the robot gets quite unbalanced at 30°. You can also tell the servos are really struggling at 30°. Much steeper than that and they'd stall completely. I took power from an laptop USB output, which I believe maxes out at 500 mA. So given a bit more juice they'd probably have managed to soldier on at a steeper angle. But still there's clearly a lot of friction in the moving parts.
Here's a closer look at the engineering horror story that makes this thing tick:
Compared to the Zero prototype, the two actuators are now about twice as long and have three jointed segments along their travel across the chassis hinge.
On the first run the actuators got misaligned and the whole thing stalled. To keep them moving along the right track I hot glued some bits of plastic under the front carriage. I also put lithium grease on joints and moving parts, but I doubt that makes much of a difference.
Clearly the chassis is too long—left and right legs needs to be spaced further apart. This design error results in the robot leaning over to one side when turning. Since I based LB-101 on the previous prototypes 3D model I just kept the same chassis width of 80 mm while almost doubling the length to 190 mm. Even though I realized this might be a problem, I ignored it in a fit of overzealous shortcut-taking. A reasonable chassis width to length ratio would probably be about 3:4.
Another issue is that the jointed actuators were pretty difficult to print and needed a lot of cleanup before assembly. Some of that is just sloppy design work on my part, but a bit of complexity is just inherent in the concept. I'd prefer that one wouldn't need a perfectly calibrated 3D printer in order to make this thing.
On the whole I'd say articulated steering is a viable method provided I put a lot more work into the design. However I'm still not convinced it's the ideal solution. The turning radius can be improved a bit but it's never going to be tight. And the internal friction will make the robot prone to breaking down after weeks of wear and tear.
The next prototype is going to be all about the new drive train discussed in the previous log. If that works out as well as I hope I will have some more options for controlling the legs movement patterns. Steering by leg movement alone has its own set of challenges but at least it will be more mechanically robust than this method.
In any case I'll put the steering design work on hold for now, and plan to take a fresh look at it in a few weeks. .
As I've previously mentioned, one of the main project goals is to use only a single servo dedicated to leg movement, rather than the two that are currently required. I've found it difficult to visualize a completely satisfying solution to the problem and I have instead decided to focus mainly on the steering issue for the time being. That priority hasn't changed, but I believe I made a breakthrough today. And since it's now nighttime and I can't sleep I might as well write a log about it.
I'll be rambling on a bit first though, so scroll down to the last paragraph if you just want the solution.
In a previous log I describe the sequence of leg movements Landbeest uses for walking. It consists of a continuous cycle of four poses: A, B, C and D.
The leg poses are controlled by two linear actuators. Let's call these L and R. They have only two resting states: Max and Min. Below is a diagram that relates the resting states of L and R to each pose.
In the transition between two poses, an actuator either moves to its opposite state or remains inactive. Only one actuator moves at any transition.
My old crappy solution
There are three major parts to this problem that has made it a little tricky for me to work out a solution:
One part of the problem is how to achieve reciprocating linear motion.
With the current 2-servo design i used servos with 180 degree rotation mounted in this linear sprocket actuator I got off Thingiverse. That's fine as long as there's one servo per actuator, but not if one servo is supposed to move both. For a 1-servo design I'd need to use a continuous 360 degree servo instead. (I'm kind of glossing over how I came to that conclusion, sorry about that.) There's a couple ways of converting rotation to back-and-forth linear motion. I decided on the mechanically simple method used by this device.
The second part is that each actuator should only move half of the time. To do that for a single actuator isn't that hard:
The red gear is connected to the servo and spins continuously in one direction. It's only toothed halfway around so each turn will rotate the orange gear by half, move the yellow actuator to it's opposite extreme position, after which it's stationary for the rest of the red gears turn.
So that's the L actuator taken care of. The third part is where it gets crazy:
Yeah! So the gray gear is coupled to the same servo shaft as the red gear. It does the same thing for the R actuator (blue) as the red gear does for L, only delayed by one half turn of the servo. It's hard to tell from the picture, but the transparent gear is identical to the orange one only turned upside down. Here's the same image without the transparency:
While I see no reason why this won't work in theory, there sure are plenty of practical issues with it. Assembling the parts could be quite tricky since each gear must interlock with the right tooth of its neighbor. The assembly must be contained in a housing where the orange gear is mounted to the floor and the purple gear to the ceiling. But the most damning problem is that there's nothing in the mechanism itself that stops the orange and purple wheels from slipping out of alignment while they're not engaged. And I can't think of any worthwhile add-on to remedy that.
The right (?) solution... (Yes I believe it is!)
I finally saw the light today when I was browsing Youtube for some sweet reciprocating piston action and stumbled over this video:
I learned two things from it: First that the wheel and piston assembly I've been using is called a "Scotch yoke". But the major...
I was very encouraged by how well the Landbeest Zero prototype performed. Of course, the glaring weakness of that design is that it can only walk along a straight line.
I'm now about to start cobbling together Landbeest 101 which is supposed to have turning capability. I'm not going to aim for a polished or even fully functional design at this point. With this upcoming prototype I'm only looking to prove to myself that the chosen steering method can get the job done at all.
The method I've decided on is what I previously called "pivot steering". But after consulting the web I've realized that's something different from what thought it was. I believe the term I'm looking for is articulated steering—the same method used by front loaders.
Zero to 101
With LB-101 I want to keep as much of the old design as I can get away with, in order to get the next prototype up and running as soon as possible. Here's what I'm starting out with:
It's a rigid chassis with two linear actuators, which are each coupled with a pair of legs.
To achieve articulated steering I want to split the chassis in a front and a rear carriage, connected by a hinge. The front carriage then houses the forelegs while the rear carriage houses the "engine" and the hindlegs. Ultimately the hinge is supposed to be controlled by a dedicated servo. But with LB-101 I want to keep it simple—I'll just turn it manually for now.
With no motor in the front carriage, there still needs to be some way to transfer motion from the actuators to the forelegs. Since the front carriage needs to turn along the hinge, I obviously can't use a completely rigid structures for that purpose. In the illustration above the dashed arrows indicates that whatever is used to transfer motion to the front carriage needs to be able to flex along with the hinge. Also, the structures transferring motion must not run along the sides of the chassis, since the distance between the actuators and the forelegs changes as the front carriage turns (center figure). Instead they must be aligned with the hinge axis (right figure).
My immediate though was to use bicycle brake cables to transfer linear motion across the hinge. However, since I'd like the Landbeest to remain fully 3d printable (well, save a few M3 screws) I'd prefer not to use it. For the same reason I won't consider using some type of pulley system.
Maybe since my mind was already on bicycles I then thought of a bike chain. Surely there must be a bike chain model somewhere on Thingiverse. A chain is a clunkier solution for sure, but as long as it's path is guided along a channel it should do the job.
Ultimately I ended up with this cable chain instead. It's print-in-place, and since its parametric I can shrink it to a size more suitable for this application.
Quick test of cable chain acting as linear actuator below:
So far so good...
It will probably be a few days until I get the time to chop apart the Landbeest chassis in Tinkercad. I figure it's a 50-50 chance I can actually get this to work, but at least it's worth a shot.