Design To Ease Reusing Bearings Pressed Into 3D-Printed Parts

Once general suspension geometry of Sawppy the Rover had been sketched out, it’s time to start building suspension components. The general construction technique has been documented, it just takes a lot of sweating the details to make everything work together as intended. Like any design endeavor, the first draft is never quite right and every part takes a few iterations to mature.

When a 3D printed plastic part turns out to be flawed for one reason or another, the plastic is effectively lost. Many people find this wasteful, some are working to recycle the plastic in some way, but nothing practical just yet. I’m not interested in recovering the plastic right now. The bearings I had pressed into the plastic components, however, are another matter.

Unlike the plastic, the bearings are easily reusable in follow-on design iterations of the part. Since the plastic is forfeit anyway, we can cut plastic apart to recover these bearings, but such cutting has to be done carefully to avoid damaging the bearing. It would be better if we can remove bearings in a way that’s more reliable and less likely to cause damage.

To help with this process, I’ve started incorporating access holes into suspension components that are useless to the rover itself. In fact, it might be a bit detrimental by weakening the component to some degree. The purpose of these holes is to provide physical access so there’s leverage to pry these bearings loose without cutting. Here’s one of the earliest steering knuckles (right) next to a more recent iteration (left) that provides an access hole to push bearings out for reuse.

 

Bearing Recovery Assist

In theory, once component design is final, these holes can be deleted so I can print a seamless and full strength part. In practice, I’m probably never going to stop tinkering with the design or, even if I do, I don’t foresee throwing away a perfectly functional part purely for the sake of printing one without the access port. I may release designs without bearing recovery port for others to print, but my own rover development chassis will always be Swiss cheese.

Copying Curiosity Rover Suspension Geometry for Sawppy the Rover

Now that we have a rover wheel that can drive and steer, it’s time to figure out how all the individual wheels relate to each other. This is the most important part of making a motorized model of Curiosity Mars rover: copying its sophisticated rocker-bogie suspension system. It is critical for appearance because a huge part of Curiosity’s unique look comes from its suspension. It is equally critical for functionality, as the suspension grants Curiosity its ability to traverse rough terrain. It wouldn’t be a model of Curiosity at all without its suspension!

On the flip side, copying Curiosity’s suspension also means taking on some of the trade-offs that made sense for Mars but not for Earth. The first example is that Curiosity’s suspension had to fold up for its journey to Mars, which our rover model would not need to do.

The second example is that the rocker-bogie suspension system is most capable climbing using the bogie, which is why JPL’s Open Source Rover (and ROV-E that proceeded it) had their bogie in the front. Curiosity has its bogie in the back. I asked why Curiosity is more capable going backwards than forwards and the answer was that Curiosity must be able to back out of whatever situation it gets into. If a little rover got stuck here on Earth, we can walk over and pick it up. If Curiosity got stuck on Mars, the nearest tow truck is many millions of miles away.

There are more sacrifices of similar nature, but since the model is intended to be mechanically faithful, we’re going to accept all these downsides of copying the design. So, onward to the internet to find references! While there are many pictures of Curiosity rover, it was unexpectedly difficult to get an isometric three-view drawing. The best I could find was in a JPL presentation MSL Rover Actuator Thermal Design (08-0699.pdf) for Spacecraft Thermal Control Workshop 2008. Page 6 of this slide deck had a good side view of Curiosity with major dimensions labeled.

This diagram became my primary reference for Sawppy the Rover. I copied it into Onshape as an image overlay and drew Sawppy’s component layout on top. This gave us a very high fidelity in the side view, unfortunately no similar top view diagrams were found so I had to guess using less precise images as reference. After some fiddling, I got a reasonable facsimile of Curiosity rover. Compare the rough sketch in Onshape with a JPL official photograph of Curiosity.

 

RockerBogieLayout

Comparison: Curiosity rover at JPL Mars Yard

Cropped Curiosity rocker bogie reference

 

Pros and Cons of Common Steel Shaft for Sawppy the Rover

Steer vs Drive Shaft

After the decision was made to use a common servo mounting bracket for both driving and steering Sawppy the Rover, the obvious next question is: why not use a common shaft design as well?

Consolidating to a common shaft design reduces the number of unique parts to keep track of, and has the potential to make fabrication easier. This reasoning made sense for servo brackets, who benefits from this commonality with no downsides.

Sadly, in the case of these steel shafts, there are functional downsides.

The servo side is not an issue. Since all servos use the same mounting bracket and coupler, the dimensions are obviously identical on that front.

The output side aren’t common and there are some minor reasons why. For the steering shaft, output section length matches the thickness of the steering knuckle. The driving shaft’s output section is longer, because it has to fit into the wheel hub as well as extending into the wheel itself for structural support. An experiment with a shortened shaft showed this length is an important guard against wheel torsional flex so we shouldn’t shorten it. Therefore a common shaft demands that the steering knuckle needs to be thicker where it meets the shaft. If we keep the existing mating location and extend shaft downwards, it reduces wheel clearance. If we move the mating location upwards, it increases the mechanical leverage of wheel load acting on the steering joint making its job harder. Both of these options are undesirable.

But the deal-breaker is the section in the middle – where the shaft is supported by a pair of bearings. The drive shaft has a short section in order to make room for the servo to be completely enclosed within the width of the wheel. Lengthening this section is not an option.

Neither is shortening the bearing support center section of the steering shaft. Forces coming in from wheel motion has great mechanical leverage on this joint and we want the bearings spaced apart to deal with this incoming torsional stress. There’s a chance the close spacing of the wheel shaft bearings might actually be sufficient to bear this stress. It might be worth exploring in a later version of the rover, but for the first edition we want to build it strong. Which means keeping shafts designs different with the steering shaft longer than the driving shaft.

Failed Attempt At Built-In Servo Saver

In the world of remote-control vehicles, there’s a category of devices called “servo savers”.  For RC cars, this shock usually comes from driver error sending the car into a wall. The obstacle tries to push the wheel in a different direction than what the steering servo was told to hold. If the obstacle is immovable enough and the collision occurs fast enough, this sharp and sudden force usually dissipates by turning a servo gearbox into little fragments of gears. A servo saver absorbs this sudden shock and releases the stress over a longer period of time, softening the blow to prevent component damage.

Sawppy the Rover is not expected to drive at high speeds, but sharp shocks to the system are still possible. For example, if someone kicks a rover wheel or a wheel drops off a rock. As the steering mechanism was being redesigned to accept a common servo bracket, it incorporated an outlet for sudden shock in the form of a narrow neck connecting servo bracket to the rest of the steering joint.

Here’s the steering joint with experimental shock absorption (left) and without (right)

Aborted Built-in Servo Saver

A little testing with the tricycle steering test rig showed a servo saver is more than just a point to absorb shock. It is also important for a servo saver to be rigid in normal operation so it does not affect normal behavior of the device.

While this narrow neck does indeed bend to absorb sharp shocks to the system, it also bends in response to small forces. This makes normal steering sluggish and unreliable. With this narrow neck, some unpredictable amount of steering force is absorbed instead of transmitted to the wheel as intended, then that lost steering force may reappear at unreliable times as the neck snaps back to being straight.

A proper servo saver would hold rigid until a threshold force is encountered, then it gives way to absorb shock. Without such capability, this narrow neck design was not a real servo saver… it’s just an unreliable steering mount.

Sawppy Rover – Common Servo Bracket

Since Sawppy the Rover is a one-man show and not a rigorously designed project, head-scratching things happen from time to time. One such instance occurred up when designing and building a test steering mechanism for the tricycle test gear. Sawppy will be using ten identical LewanSoul LX-16A serial bus servos for all its wheel actuation duties. Six acting as drive actuators and four as steering actuators. All ten will be coupled to 8mm steel shafts for their respective duties.

So when assembling the tricycle test rig, I noticed that I had used identical shaft couplers but different mounting brackets for these servos in their different roles: one bracket for driving, and a different bracket for steering. This was not a deliberate decision. I just drew up a bracket as I went and failed to think about the big picture.

Once I stopped and gave it some thought, I noticed a lot of commonality beyond the obvious fact they’re holding identical servos. In both cases, they don’t need to take up any part of rover’s structural load. That is taken up by the bearing + shaft assembly. All a servo has to worry about is putting torque on that shaft. This meant the workload is similar from a servo’s perspective and hence all servos can use the same bracket.

Using a common servo bracket for all roles mean we can print ten identical brackets instead of keeping track of several different types. Using a common mounting mechanism also means it’ll be easier to adapt Sawppy to use a different servo in the future: we only have to design one bracket and print ten copies.

Once this “aha” moment struck, it was fairly easy to reconfigure related components to accept a common servo bracket. Fortunately this insight occurred before full scale rover construction had commenced. Now we have increased ease of build, simplified parts inventory, with no noticeable loss in functionality.

Here’s a picture of the new mechanisms using a common servo brackets (left) versus old mechanisms using distinct drive and steer brackets (right).

Common Bracket

Rover Wheel Tricycle Tests Steering Mechanism

If you’re reading these Sawppy the Rover construction blog posts in sequence, you should have predicted what was coming. After the first test using a 180mm wheel on a stick, we had two 120mm wheels on a stick. And now…

Tricycle test rig

Three wheels on a stick.

The pair of wheels side-by-side have no motors driving them, and they share a 8mm steel shaft solid axle. They are not the focus here, the focus is on the third wheel here to verify our steering mechanism is going to work.

Unlike the previous servo wheel drive experiment, we’re fairly confident in this servo’s ability to steer. This serial bus servo is a close cousin of remote control hobby servos, which are used extensively for steering in remote control cars and boats as well as RC aircraft control surfaces. This is what it was designed for, it’s a very powerful servo for its size, it was able to steer without problems even with some weight placed on the aluminum extrusion beam to simulation rover mass. In fact this test rig worked better with some weight on the front as that is the only driven wheel.

The focus of this test was more about how the steering knuckle is mounted to the end of the aluminum extrusion beam, how it tolerates load from rover chassis, how the servo is coupled to the 8mm steel steering shaft, and other mechanical details of that nature. Like some earlier component tests, this test was mainly just to make sure nothing silly was overlooked in the digital design phase.

Functionally, this mechanism worked perfectly well.  The two- and three- wheel test rigs give us confidence a six-wheel rover with servo drive and steering will work.

The question this test rig raised was not about functionality, it was about design and construction. There’s room for improvement with common shared components, an idea to be explored in the next post. (Apologies if you are disappointed the next post is not about “four wheels on a stick.”)

Oldie But Goodie: Two Wheel Differential Drive Test for Sawppy the Rover’s Wheels

What’s the most obvious test after we’ve tested a single wheel on a stick?

Obviously, two wheels on a stick.

More specifically, a two-wheel chassis for testing wheel performance when driven by LewanSoul LX-16A servos.

Sawppy Differential Drive

After detents were cut in wheel drive axles and hooked back up to 180mm diameter wheels, it gave us firsthand feel of how strong the wheels can drive along the ground and… it’s a little worrying. A 180mm diameter wheel might be too big for these little servos to turn effectively.

But because a proportional Mars rover model with 180mm diameter wheels would be over a square meter in footprint, Sawppy wheels were downsized to 120mm in diameter. Smaller wheels are also easier to drive. Once the first two drive axles (with detents) were cut for 120mm wheels, they were assembled into a two-wheel differential chassis pretending to be the two middle wheels on a six-wheel rover.

This followed in the footsteps of SGVHAK rover, where we also tested our first two wheels with a two-wheel differential drive chassis. The difference is now we have an existing software package to adapt to this chassis, so we could focus on evaluating wheel performance.

These servos seemed OK turning 120mm diameter rover wheels. We’re getting encouraging torque and this chassis could drag itself along the ground at a decent speed. It looks like servo-based wheel drive is indeed going to work.

And now that we’ve validated servo driven wheels, it’s time to examine servo steering.

Poor Man’s Lathe: Cutting a Steering Shaft With Drill and Dremel

Sawppy the Rover’s design included several uses of 8mm steel rods to transfer motion while supported by a pair of 608 bearings. While I could personally ask nicely and access a metalworking lathe, not everyone would be so lucky. So I wanted to prove the rover could be built with basic tools, like this jury-rigged lathe.

In this setup, our 8mm steel workpiece is rotated by a drill. To help hold the shaft steady, one of the earlier iterations of a wheel steering knuckle (more specifically, the pair of 608 bearings already installed in it) was used as a crude steady rest. A Dremel tool with cutting wheel will create the features we want in steel.

PML 1 - Drill, Dremel, Bearing

One feature we want to create is to cut a groove for a retaining clip.

PML 2 - Dremel Cutting Wheel for Retainer Clip Slot

A retaining clip wants a groove with a squared-off bottom. A Dremel cutting wheel will inevitably round off itself (especially if we fail to hold it square to the workpiece.) To restore the squared-off profile of a cutting wheel, almost every Dremel tool kit comes with a stone that is strong enough to stand up to the cutting wheel. We can then spin up the Dremel and use this stone to reshape wheel profile back to our desired square.

PML 3 - cut a slot with square inside

The other feature we want to cut is a flat in the shaft as a detent for set screw to bite and hold position. This can be done by leaving the shaft static (not spinning) and running the cutting wheel back and forth on one side. For a set screw to hold position, it does not need to be perfectly flat, it just needs to be not round.

Some sharp edges may remain after steel cutting operations. Protect against cutting our fingers by cleaning up edges with a file. Alternatively, for people with a nice heavy vise available, use the file to create set screw detents instead of Dremel. (More details on this option later.)

PML 4 - clean up with a file

Two retaining clip grooves plus two detents later – we have a steering shaft!

PML 5 - steering shaft

 

Sawppy the Rover’s Wheel on a Stick

Early on in development of Sawppy the Rover’s wheel and steering knuckle mechanism, it was useful to do a quick physical test to make sure nothing silly was overlooked in digital design. The rover has six wheels, but we only need one to start. Introducing the Wheel on a Stick!

Test Wheel on a Stick

This test rig lets us put load on the wheel steering subsystem in a way that’s much closer to how the rover will work. By holding the aluminum extrusion and pushing it in various directions, we could get an idea how this subsystem will react with more confidence than we would if we were just pushing on the individual pieces with our hands.

And once the basic mechanical pieces were proven to work, servo motors were installed to test how it all moves. Reading servo spec sheet is one thing, actually seeing it move in person and feeling the actuator forces should be quite a confidence builder. Or it would be, if the servos had any traction.

Both drive axle and steering joints had their bearings and 8mm steel shafts here, but they did not yet have slots for retainer clips and more importantly, they did not have detents for set screws. As a result the couplers didn’t grab very tightly. All we could tell is that these LewanSoul LX-16A serial bus servo motors are stronger than our shaft coupler’s grip, which isn’t very much.

We could still go without the retainer clips for a bit, but before we can verify we have enough motor strength for a rover, we need to put in those detents and set screws.

Sawppy the Rover’s Steering Knuckle

Design for Sawppy the Rover started, just as SGVHAK rover before it, from the ground up with wheels. Once there was enough confidence we have the wheels to make a successful rover, design work proceeded upwards to the bearing system we’ll use to support the rover’s range of motion, and now we look at the steering knuckle that will hold the corner wheels while they steer.

Knuckle Highlight

Design for this part is complicated by our desire to keep as much of our wheel mechanism inside the wheel as possible. Fewer protrusions from the wheel means fewer rocks and other things to collide with as the rover rolls along. The final design ended up looking like a question mark. Starting from the steering joint, sweeping to the inside of the wheel, then curing towards the outside again to hold wheel bearings while making as much room as possible for the servo motor driving the wheel.

When designing a part to be 3D printed, an important consideration is which way to orient the print layers. A print is strongest when forces are handled along the print layer because the adhesion between layers is usually what breaks first. (Similar to how wood grain works.) For this steering knuckle, there was no obvious right answer. Load comes from several different directions: The wheel axle from below, the steering joint from above, and weight of the rover in between held by its awkward shape. None of which apply force in the same direction as any of the others.

Orientation will thus necessarily be a judgement call making it strong in one axis at the expense of others. The final decision ruled in favor of making the part strongest for handling rover weight, we’ll leave our bearing & shaft assembly to help handle the wheel driving and steering forces. Concern about strength has already proven to be a real issue, as shown by this crack in a knuckle right next to wheel drive axle bearings.

Steering Knuckle Crack

Fortunately the rover was able to continue running in this state, but it does pretty clearly tell us there’s still room for improvement here.

And this is only one of the many problems involved in designing this steering knuckle. Building these knuckles, testing them, and fixing the problems that were exposed, meant there were a lot of iterations of steering knuckle designs.

Steering Knuckle Generations

 

Sawppy the Rover’s Steel Load-Bearing Parts

3D printed plastic will be a huge part of building Sawppy the Rover, but 3D printed plastic has some very definite limits. The chassis construction technique article covers use of aluminum extrusion beams for large fixed elements, this post discusses the steel parts involved in moving elements: ball bearings, steel shaft, and e-clip holding them all together.

Bearing Shaft and Clip

Every part of Sawppy’s body that requires a rotation motion will have some variant of this assembly. The bearings are commodity “608” type ball bearings. High quality capable bearings are expensive, but mechanical demands for a little rover model is quite modest so they don’t need to be very good. In fact, bearings that fail QA for their primary purpose might work just fine here. Which is good, because such rejects are how some of the lowest priced vendors on Amazon and eBay get their inventory.

These ball bearings can take load both along their radius and along their axis. What they can’t take very well is a torsional load. This can be mitigated by using a pair of bearings side by side to balance the load. The wider apart the pair are, the better they can resist twisting.

Inside this pair of bearings is an 8mm steel shaft cut to length as needed by the design. When the shaft is used to transfer torque, detents are cut into the shaft so we can install couplers with set screws. And when the shaft needs to stay in a certain place relative to the bearings, grooves are cut into the shaft so retainer clips can be installed to keep shaft in location.

This general pattern is used in the following locations on Sawppy the Rover’s body:

  • Driving: Each wheel has one of these assemblies so the driving servo motor does not have to bear rover’s weight, it only has to drive.
  • Steering: Each corner has one of these assemblies so the steering servo motor does not bear the rover’s weight or physical loads from wheel motion, the servo only has to steer.
  • Suspension: Each wheel bogie pivots on one of these assemblies at the end of a rocker, and each rocker pivots on a similar assembly where it joins the body.

 

Cat Treat Toy

And now a change of pace from rover design: a cat toy! The intent of this project was to build an enrichment toy for a cat. It provides a bit of physical activity and also provide rewards in the form of an occasional cat treat.

The design goals were:

  • Printable on inexpensive 3D printers.
  • Spherical exterior so a cat can bat at it and have it roll around.
  • Hollow interior to hold some bits of cat treats.
  • Holes in the exterior so treats would occasionally drop out as the cat plays with it.
  • Can be pulled part for treat refill.
  • Can be printed without print support material.

Cat Treat Toy

The simultaneous demands of spherical exterior, accessible hollow interior, and no support is a challenge for low-end hobbyist level 3D printers. Mid- and high-range printers have features like water-soluable support material which makes arbitrary shapes easy to build. Low end printer projects need to be designed to print on a flat print bed. In this case, the ball has to be printed as two hemispheres.

If each hemisphere had equal thickness walls throughout, the polar parts of the hemisphere would have been a challenge to print without supports. The top of the sphere will almost certainly sag due to overhang and ruining the spherical shape. Fortunately there was no requirement for the interior to be spherical and we could work around this issue by making the interior into a cone that can print without supports.

We then move on to the next challenge of joining two hemispheres. This was solved by printing a third piece – a springy clip that sits inside of our sphere’s “equator” and shaped to hold the two halves together. Here’s a cross-section view of the clip and the two hemispheres.

Cat Treat Toy Cross Section

If this springy clip was too weak, the sphere will fall apart as the cat plays with it. If it is too strong, the human will have a hard time pulling it apart for refill. So it requires some tuning to find a sweet spot as every printer is a little different. Thanks to Onshape’s ability to adjust parameters, the lucky cat’s owner could fine-tune how much surface area to put on this clip and how much bending spring to put into its shape.

This cat toy is freely accessible in Onshape’s Public Documents library to be copied and modified, which is exactly what happened for at least one cat.

Sawppy the Rover’s Wheels: Second and Third Drafts

First draft of Sawppy the Rover’s wheels exposed some problems that needed to be addressed in follow-up revisions. The first goal was to push the motor assembly further into the wheel so it does not protrude beyond the width of the wheel, to avoid collision with ground obstacles. The second goal is to change its proportions so it looks more like wheels on our inspiration Mars rover Curiosity.

After a little research, I found that Curiosity’s wheel’s width to diameter proportions are about 30% wider than our first draft. This is great news – by widening our wheel to match Curiosity proportions, the motors will end up inside the wheel, solving both problems at once.

When the second draft wheels were printed and assembled, it accomplished both goals. The wheel look like Curiosity wheels, and now only the suspension arm protrudes beyond wheel width. I then printed a few more copies at different wheel and spoke thicknesses… and again this was premature. There was a big problem staring at me in the face. Emphasis big.

When first draft was designed, I specified wheel diameter of 180mm. This number came because I wanted to see if it would print well on a 3D printer with 200mm x 200mm print bed and 180mm seems like a good value leaving a 10mm margin on all sides. Now that I have Curiosity rover dimensions in hand, I could answer an important question: If the model has proportions faithful to Curiosity, and wheels are 180mm in diameter, how big would the rover be?

The answer: a little longer than 1 meter, a little wider than 1 meter, for overall footprint greater than 1 square meter. That’s big! In fact that’s too big to navigate normal household hallways and doorways, or even fit in my car for transport. So for the third draft, the wheel diameter was shrunk down to 120mm. This still leaves enough volume inside the wheel for our servo motors, and results in a rover that should be an interesting size but not so large to be unwieldy. 120mm also happens to be the print bed dimension of some popular mini 3D printers, enabling them to print these wheels. (In theory, at least.)

From left to right, the first through third drafts of Sawppy the Rover’s wheels.

SawppyWheel3Gen

 

Sawppy the Rover Wheels: First Draft

I had some design goals in mind for how the wheel should behave. Some portion should be flexible to absorb shock, and others places need to stay strong against different forces. In theory I could model this digitally, in practice it was more fun to 3D print them and feel how they act in the real world. A very crude suspension arm and motor mount was printed so some quick tests could be done.

SawppyWheelv1Parallax

There were three variables under adjustment. First is the thickness of wheel circumference. We want it to be rigid enough to support rover weight, yet soft enough to help wheel traction and absorb some shock. The second is the thickness of wheel spokes, with similar trade-off. Each spoke consists of a curved outer portion that’s intended to be relatively soft, backed by a straight portion that would be more rigid. The third variable is adjusting the size proportion between straight vs. curved.

A few different variants were printed to test how these variables affected wheel performance, and in hindsight this was premature. Adjusting these parameters is something that had to be redone after every significant change in wheel design, and there were some changes still to come.

The first major change was bearing location. This draft placed them in the center of wheel width, which turned out to be overkill and took up space. We would much rather allocate more space to the motor, which sticks out in this first draft. This protrusion risks colliding with obstacles the wheel could otherwise roll past, we much rather have the motor completely enclosed within the wheel.

SawppyWheelv1Protrusion

This motor is an old Parallax continuous rotation servo motor that was on hand. Its rated torque of 38 oz-in proved to be woefully under powered for driving a wheel of this size, but there’s no need to worry just yet. There are far more powerful servos available within price range for this project. Browsing Amazon I came across LewanSoul LD-20MG, with a quoted torque of 277 oz-in. That’s a good candidate to experiment with.

The second major change was wheel proportion. The diameter-to-width ratio is visibly different from Curiosity rover’s own wheels. Visual and mechanical fidelity is a priority in this project so this proportion – which has huge effect on wheel behavior – still needs to be changed.

Sawppy and SGVHAK Rovers at SGVLUG May 2018 Meet

SGVLUG201805

Yesterday was the monthly meeting of San Gabriel Valley Linux Users Group (SGVLUG) for May 2018. SGVHAK, the maker hacker group who built a rover, is a subset of SGVLUG and we got to present our project to the wider community.

The night’s presentation started with Eric Junkins of JPL talking about how JPL’s Open Source Rover came about. Several groups were invited to beta test the build instructions before public release (coming in a few weeks, says Eric) and this was the stage where SGVHAK got involved. SGVHAK made a few changes to the baseline design for our own take on the project, exactly as the nature of open source release intended.

Towards the end Sawppy the Rover got a few minutes in the spotlight as a spin-off rover that was inspired by JPL’s Open Source Rover project. I got to talk about how it came out of an offhand comment by Eric and eventually I delivered a basic chassis that met his challenge of a $500 price point. It is not as fast, nor as powerful, nor as flexible as the JPL open source rover design. These were all trade-offs made in the name of hitting that price point.

After the presentation both rovers ventured out to the parking lot behind our meeting location (Du-Par’s Pasadena) and ran around for a while, attracting attention from passers-by along the way. The rovers may have managed to recruit a few new members to SGVLUG. We’ll see!

Sawppy Feet 1.0: Rover Wheel Design for 3D Printing

Based on past experience building with aluminum extrusions and 3D printing, I was confident I could build most of the rover structure. The construction technique I used had been evolving through the Luggable PC projects and was further refined by building Sawppy. It ended up as a Hackaday.com article to be shared with the world.

But the wheels? That was a question mark early on. 3D printing a rover wheel was an important part of hitting our $500 price target. If we have to buy commercial remote-control monster truck tires and wheels like the baseline rover, that would take a pretty big bite out of the budget.

Besides cost, we also want our wheels to resemble that on the actual rover, with extra brownie points if we can also replicate some functionality. Curiosity’s misfortune is my luck in this case – thanks to unexpected wheel damage on the Curiosity becoming a news item, there are lots of online pictures of rover wheels for reference. I also had the chance to take a nice close-up picture of a model of Curiosity in the lobby of a JPL building.

Lobby Curiosity Wheel

We see six spokes, and the shape of each spoke shows an integration of two distinct mechanisms. The outer ~80% of the wheel stands at a shallow angle to the outer rim, making it amenable to bending to absorb shock. The remaining spokes stand perpendicular and can still help with shock absorption but will be much more reluctant to do so.

Another important detail is that the wheel mounting point towards the outer far edge of the wheel. So the spokes must be simultaneously soft to up-down forces but strong against twisting forces to make sure the wheel surfaces stay flat against the ground.

These spokes were machined from titanium and their shape isn’t something we can duplicate with hobbyist level 3D printing. However, we can copy the general profile which will give us some of this two-stage shock absorption mechanism. And by extending our imitation spoke across the width of the wheel, we gain the desired strength against twisting forces without using titanium machined parts.

This is pretty good for a first draft, but there’s more fine tuning to be done to this design.

Sawppy Wheel v1

 

 

Before We Begin: Make Sure Sawppy the Rover Is Feasible

Servo RoverAs mentioned yesterday, Sawppy the Rover started with an offhand comment made by a member of JPL’s Open Source Rover project discussing possible variants on their baseline design. One common piece of feedback on the baseline was its cost, and like good engineers they’ve brainstormed potential methods to reduce cost.

One idea – the one I took and ran with to create Sawppy the Rover – was to use remote-control hobby servos as actuators. The baseline designed used RoboClaw motor controllers hooked up to motor gearboxes monitored by position encoders. This is a very capable and precise system that gives a lot of headroom for a rover project to grow in sophistication, but all that capability costs money.

A hobby servo combines all the components into an inexpensive self-contained unit. A motor, its gear train, a potentiometer for closed-loop feedback, and the motor control circuit to make it all work inside one box. This integration also reduces parts count and construction complexity of the rover. It seems worth making the trade-off against power, speed, and the ability to monitor precise position.

Another piece of feedback for the baseline rover was its use of Actobotics construction system for robot structure. Again, this is a very capable system that gives easy flexibility to experiment with different robot configurations, because it is basically an Erector Set for robots. But again, this flexibility costs money.

3D printing would allow individual rover components to be created at a lower price. The trade-off is that the rover would be less convenient to reconfigure, since it would require different pieces to be printed instead of just unbolting Actobotics parts and bolting things back on in different places. And even though 3D printed plastic won’t be as strong, they should be lighter than Actobotics metal parts thereby reducing workload on the less powerful hobby servo motors.

Following engineering tradition, a quick back-of-the-napkin calculation was made to see if the project is in the ballpark to be feasible. The baseline rover is a little over 20 pounds. If we guess at a 25% weight reduction from using 3D printed plastic, that gives us a target of roughly 17.5 pounds, or roughly eight kilograms. Hobbyist grade 3D printing plastic filament is sold in one kilogram spools for roughly $25 each, depending on plastic type and quality.  8 x $25 = $200 for plastic filament if the rover is completely printed. Which it won’t be, this is just for the sake of a rough estimate.

We’ll need ten actuators to build a mechanically faithful rover model. (Six to drive each wheel, four to steer each corner.) Hobby servos are available for $20 or less, 10 x $20 = $200

This gives a rough estimate of $400 leaving another $100 for Raspberry Pi and remaining components. Once a $500 servo-actuated, 3D printed rover is determined to be feasible, Sawppy the Rover project was underway.

Rover Romping at JPL: First Public Appearance of Sawppy the Rover

Today was the first public appearance of my next rover project: Sawppy the Rover. Well, the local maker group SGVHAK has seen Sawppy from prototypes of individual parts, but this is the first time it was shown to people I didn’t already know.

The event was at JPL and Sawppy got to romp with its predecessors. The whole story starts with JPL’s Open Source Rover project (whose web site will launch… any… day… now…) serving as our baseline. In January, a team was formed from SGVHAK members to beta-test their assembly instructions and submit feedback. During the test/feedback/review process, I had the chance to talk with Eric Junkins of JPL. At some point Eric tossed out an idea that somebody might take this build-it-yourself rover concept in another direction and design a servo-powered, 3D-printed version.

After SGVHAK’s rover project was complete, Eric’s idea kept coming back up in my head. Eventually I decided that “somebody” will be me, so I started drawing up plans for a rover that uses servo-actuated wheels and 3D printed interconnects for extrusions. Thinking like an engineer, at first I turned that description into an acronym: SAWPIFE. But then I turned that into the name Sawppy hopefully making it more approachable.

Here’s the rover lineup at JPL today: Eric is in the back (center) standing by his black & red rover. SGVHAK’s rover is the blue one in the middle, and Sawppy is the white rover sitting in the front right.

Sawppy JPL IT Expo

Today also marks the first public appearance of Sawppy online, albeit indirectly. I wrote up my construction technique for Hackaday.com and Sawppy served as cover model for that article. Sawppy is open for anyone to look over and maybe build their own, with its own Hackaday.io project page, Github repository and a public Onshape CAD document.

Over the next several days, this blog will detail adventures in building Sawppy the Rover.

SGVHAK Rover Interface Avoids Confirmation Dialog

Shutdown Reboot

Our SGVHAK Rover’s brain prefers to be shut down gracefully rather than having its power removed at an arbitrary time. If power cuts out in the middle of a system write operation, it risks corrupting our system storage drive. While our control software is written to be fairly platform-agnostic, we’re primarily running it on Raspberry Pi which lacks a hardware shutdown button. So we need to create an UI to initiate a system shutdown via software.

The easiest thing to do would be to add a “Shutdown” button. And since it is a rather drastic event, have a “Are you sure?” confirmation dialog. This historically common pattern is falling out of favor with user interface designers. Computer users today are constantly inundated with confirmation dialog making them less effective. If our user has built up a habit of dismissing confirmation dialog without thinking, a confirmation dialog is no confirmation at all.

So how do we enforce confirmation of action without resorting to the overplayed confirmation dialog? We have to design our UI to prevent an accidental shutdown from a wayward finger press. To accomplish this goal, our shutdown procedure is designed so user must make a deliberate series of actions, none of which is “Yes/No’ on an ineffectual dialog box.

First – our user must enter a “System Power” menu. If they entered by mistake, any of the three active buttons will take then back to main menu. There’s no way to accidentally shutdown with a single mistaken tap.

Second – they must select “Shutdown” or “Reboot”, forcing a deliberate choice to be made before our UI activates “OK” button. If an incorrect selection is made, it can be corrected without accidentally triggering the action because both options are on the far left of the screen and “OK” is on the far right. Bottom line: Even with two accidental presses, our system will not shut down or reboot.

Third – With the “OK” button now activate after two deliberate actions, the user can tap it to begin the shutdown (or reboot) process.

SGVHAK Rover Steering Trim Adjustment

One of the changes we made to our SGVHAK Rover relative to the baseline design was a decision to omit absolute encoders for our corner steering motors. The baseline design used absolute encoders so it knows every wheel’s steering angle upon system startup, but we decided to sacrifice that ability in exchange for cost savings (~$50/ea * 4 corners = ~$200.) Since there is no free lunch, this decision also means we have additional work to do upon our system startup.

Our control software launches with the assumption that all steerable wheels are pointed straight front-back, which is of course not always true. We could manually push the wheels to straight front-back orientation before turning on power, but that’s not great for the gearbox. Also, the shaft coupler used to connect our motor gearbox to our steering mechanism is liable to slip. (This is considered a bug even though it has a potential feature: in theory sharp jolts to the system would slip the coupler instead of breaking something else in the system. In practice, we found that it didn’t slip enough to avoid breaking a gearbox.)

Given both of these scenarios, we need a software-based solution to adjust steering trim on the fly. Once our RoboClaw motor controller is told where zero degree position is, it is quite capable of holding a commanded angle until the coupler slips or the system reboots, whichever comes first.

Steering Trim

Steering trim adjustment took the form of a multi-stage HTML form designed for our specific workflow. First our user chooses a wheel to work with, and they are directed to do so because every other UI element on the page is inactive until one wheel is chosen.

Once a wheel is chosen, the remaining UI activates and wheel selection UI deactivates to guarantee we’re working on a single wheel at a time. In this stage, steering angle can be adjusted in 1- and 5-degree increments. When we’re satisfied our wheel has been returned to zero degrees deflection, we can select “Accept Current Angle as New Zero” to commit. We also have the option to abort adjustment and retain previous zero position. Either way, wheel selection activates to allow user to select another wheel, and the rest of the page deactivates until a wheel is chosen.

We have no scenarios where multiple steering motors need to be trimmed at the same time, so this user experience specifically focus on one wheel at a time makes the process straightforward. It also becomes impossible to make mistakes caused by user thinking they’re adjusting wheel when they’re actually adjusting another, which is a good thing for positive user experience.