The SGVHAK rover team continued to work through problems and worked our way towards a first usable iteration of the rover. Wires are tidied up so there’s no risk of tangling up as the rover moves. All fasteners are tightened. The Raspberry Pi now runs as its own WiFi network access point and no longer dependent on an external wireless router. While there are many more items on the to-do list, these were the critical pieces to complete for public demonstration at SCaLE 16x.

Once it’s all buttoned up and powered up, we had what amounted to a very fancy and expensive remote-control vehicle. Unlike common toy remote control cars, this one can demonstrate the rocker-bogie suspension system used by Mars rovers. At this scale it is quite capable of climbing over people’s feet, sidewalk curbs, and decorative garden rocks.

The controls were passed around to people who came to our SGVHAK meet just before SCaLE. This is a test to see how the rover handles drivers who weren’t involved in the build process. If this goes well, we can feel pretty confident about handing the controls over to anyone who wanted a turn.

The test, sadly, did not go well. We had been suspicious that the steering motors might not be strong enough to take little rover fender-benders, despite their advertised torque rating on paper. This confirmation was sadly confirmed in the form of a broken gearbox that ended the test drive session.

Test, find problems, fix them, repeat. This is not in itself a problem. But SCaLE is only a week away and stronger replacement gearbox+motor won’t arrive until afterwards. If we want to demonstrate the rover at SCaLE, we’ll need to get creative.

It took some trudging through tedious nuts-and-bolts work (occasionally literally) before we got to our next milestone: the first system integration test.

1. Structural – the rocker-bogie suspension system assembled and can accept all six wheels.
2. Mechanical – All six wheel assemblies and all four steering assemblies ready to install on structure.
3. Electrical – all five RoboClaw modules installed on the rover chassis, with wiring harnesses built to connect all motors to their respective RoboClaw.
4. Communication – All five RoboClaw connected together into a single serial command network, connected to a USB-serial bridge that will talk to the brain. (Ubuntu PC, Raspberry Pi, MacBook, anything.)
5. Software – Ready to talk to all five RoboClaw modules and sending commands for rover mobility.

The integration test was intended to help expose problems, and it was very effectively at doing so! Some highlights:

1. While all RoboClaw were correctly configured for advanced packet serial command and on the correct baud rate, they weren’t all properly communicating because they haven’t all be set into multi-unit mode. Toggling multi-unit mode is not something that we could do with buttons on the RoboClaw so we had to hook up the individual modules to update configuration.
2. The RoboClaw motor encoder A/B are reversed between the two channels on the board, which resulted in some of our wheels running in opposite direction than the encoder expected. This meant reversing some of the motor drive power wires in order for the motor direction to agree with encoder direction.
3. The control software responded to input events as fast as it could, which far outpaced the RoboClaw communication resulting in a backlog of commands. This backlog overflowed some communication queues causing crashes.
   1. Long-term fix: The server needs to throttle event response. We settled on a maximum rate of an event once every 50ms.
   2. Short-term fix: Create an alternate UI that only sends one command at a time to avoid the crunch.

After we worked through the issues big and small, we could run the motors with the rover lying on its back. It won’t be long before we’ll be able to drive the rover on its own wheels.

Once the rover was standing on its own wheels, we knew the majority of structure work is behind us. Not that we were close to completion – there were lots of details to finish up before the structure can be declared done. And it would have been naive to believe that the structure will perform flawlessly once assembly is complete – there were many problems that need fixing.

Once the structure work started ramping down with frame assembly, many other robot work can begin with a far better idea of the actual structure we’re building around. For example, it didn’t make a lot of sense to build wiring until we knew where we have space to route those bundles. It started with prep work – cleaning up rats nests and terminating components in connectors to make assembly easier. Here’s a before-and-after comparison picture.

For the wheels specifically, we had the goal of making every wheel assembly interchangeable. Keeping all the wiring schema consistent makes it easier and less confusing to build, and allows us to build extra wheels on hand for quick replacement as needed. The only foil to this plan are the tires we’re using: the thread pattern is directional and has a recommended turning direction. The tires should work sufficiently well in either direction, but for the first draft we’ll put in the effort to align the tread patterns for cosmetic purposes if nothing else.

While building a big project, it’s good to celebrate milestones when they roll around. Here’s a picture taken back when the team first assembled all the major pieces necessary for our SGVHAK rover to stand on its own wheels.

It was cause for celebration even though there were still a lot of work to do: the wheels in the picture aren’t solidly attached yet. Posing for this picture required some careful handling to make sure they don’t fall off. The main body is basically just an empty bracket barely holding the two side assemblies together. Those two rocker-bogie assemblies still need the cross arm to connect them in order to create desired rover suspension kinematics. None of the electrical connections have been made – the wheels can’t roll on their own power nor steer. Even if they could, the software isn’t ready to drive them, either.

And we haven’t even looked at the LED display for the friendly face of the robot.

But even with wires dangling, it doesn’t look half bad. This was a pretty good morale boost for the team to see a recognizable shape coming together.

One of the main objectives of SGVHAK rover build is to beta-test the instructions before it is opened to the world. Much of this involved feedback along the lines of “this part of the instruction is not clear” or “this part is the wrong part.” But we also occasionally send in feedback of “here’s a problem we see, and here’s the solution we came up with.” An example is the how the corner wheels bear their weight.

In JPL’s original build, the entire weight of the corner wheel comes through the shaft used to steer the corner wheel (highlighted in blue) pushing into the steering gear motor. Motors are typically designed to handle rotational stress and not force along the rotation axis pushing into the motor.

In the short-term, things will push against each other until the force makes its way to the gear motor outer casing, which will then push against the motor mount and eventually make its way back down to a structural member. But this long roundabout way will cause undue wear on the gearbox and certainly reduce its life.

So we offered a solution: Add a small piece of metal to take the weight off the steering shaft, transmitting it directly from the wheel assembly to the bearing block that looks like it should be strong enough to do the job. With this addition, the gear motor no longer has to worry about supporting the weight, it can focus on its job: steering the wheel.

We think this is a worthwhile addition to our rover. Unfortunately this spacer was cut on a lathe, which is not a piece of equipment most people have access to. If the authors agree this is a problem, and agree with the general idea of our solution, we’ll need to think up a variant of this fix that would be easier to make.

The SGVHAK rover wheels were a deviation from JPL’s baseline design, hence that’s where we started to get an early lead on any problems. As the baseline design is already proven, that could start later. The point of this exercise is to beta test the build instructions and evaluate their clarity and accuracy. Given it is still an early draft, there was a lot of room for us to offer suggestion for improvement. Sometimes the instructions alone left us bewildered, and we ended up going to the CAD file to see how pieces were intended to fit together. It helps, but the fact is we still have ambiguities that might cause problems down the line. The joy of being pioneering guinea pigs! Minor difficulties aside, the main metal frame is coming together mostly matching what the instructions dictated.

Since we’re doing our own wheels via 3D printing, we had to figure out where our changes blend in to the original design. Here are the wheel assemblies while we iterate on the integration.

The aluminum U-channel are pretty easy to work with and turned out to be far stronger than the expectation formed by looking at pictures. This should be one sturdy rover. The U-channels are also really easy to work with, for the most part roughly similar to IKEA furniture assembly. However, there were a few parts that needed more extensive work. Some of this work proved to be challenging. We needed a few short segments of aluminum rod with holes drilled through them. Even with the help of a vise clamping the rod on the work table of a drill press, movement crept in. The first attempt was not usable, it took a few tries to figure out the necessary technique.

Increasing the gear lash improved performance tremendously, but still a little short of where we need to be. In an effort to improve motor control, the 3D-printed encoder wheel in our planetary gear wheel hub had its resolution tripled. This triples the number of quadrature pulses sent to our RoboClaw motor controller board, and we hoped that will enable smoother behavior. The hypothesis: with triple the pulse frequency, RoboClaw can detect changes in one-third the time and start responding faster to changes. The hypothesis was proven correct but it took a bit of work to get there.

We had to figure out how to configure the RoboClaw to correspond to the change. The most obvious parameter to update was to triple QPPS (quadrature pulses per second) to match the triple resolution. Tripling the encoder resolution unfortunately hasn’t solved our inability to use Ion Studio’s auto PID tuning algorithm (it still freezes up) so we had to return to manual tuning.

Armed with theory of PID but not details of Ion Motion Control’s implementation, we started adjusting the Position PID values and sending motor positioning commands to see their effects. First we tried tripling them, then cutting them by two-thirds, neither resulted in good response. Eventually we remembered some earlier indications that the Velocity PID seemed to have some involvement in position commands, even if we weren’t using the motor velocity commands. The Position PID values were restored to what worked before, and we start playing with the Velocity PID.

Tripling all the Velocity PID values were not fruitful, but cutting them by two-thirds felt like we were on the right track. We ended up with velocity P roughly 25% of what it was before, the I at 10% of its previous value, and D remained the same. There’s still a lot of tuning work ahead of us but this got us in the ballpark with a motor that behaves close enough to what we want.

Lessons learned:

• The Velocity PID values are not used only for motor velocity commands. They affect the behavior of motor position commands as well.
• When increasing resolution for an encoder attached to a RoboClaw, leave the position PID alone and start with decreasing velocity PID values by corresponding ratio.

After initial tests of the first two wheels, we have enough information to think our 3D printed gears are meshing too tightly. They are catching on each other which briefly require more motor power to continue rotating. This occasional spikes of power is making it difficult for our motor controller to keep speed steady and predictable.

To resolve this, a new set of gears have been 3D-printed with a slightly larger gap (gear lash) between them. The initial gears were printed with 0.3mm which was enough to compensate for imperfection inherent in hobbyist level 3D printers. This allowed assembly and start them turning, but as we found out, not smoothly. The latest gears were printed with the parameter set to 0.5mm. This will give up some precision, but we hope to get more predictable operation in return.

When the new gears were assembled, the smoother movement was immediately obvious. It ran better straight out of the 3D printer than the old tighter gears ever did. Even when the old gears were lubricated and had some time to wear in. As expected, there was greater slop to go along with this change. Rotating the wheel by hand implied the rover might rock back and forth about 1-2 mm within this gap, roughly as much as what we’d expect to be absorbed by the rubber tires. The precision has indeed decreased, but probably not enough to affect driving dynamics.

We hooked the new gearbox up to the RoboClaw motor controller to try Ion Studio’s automatic PID tuning again. We hoped the old gearbox’s unpredictable motion was why the software froze up trying to auto tune. Sadly the software still froze up and auto-tuning remains out of reach. However, the good news is that the smoother motion made manual PID tuning much easier and we’ve obtained some decent values to use as starting point. (RoboClaw position P=2400, I=0, D=1500, Deadzone=1)

We now have a wheel motor that can start turning reliably and smoothly, hold speed within an acceptable range, and decelerate to stop at a specified position. This was a hit-and-miss proposition with the old gears but the new gears make it look easy. Here’s a short clip showing the new wheel executing command to make one complete revolution and stop exactly where it started. No hesitation, no oscillation. Good stuff!

The rover didn’t always have six wheels. Since we were building our own wheel design, we wanted to make sure it works before we build six of them. Here was our first integration test chassis: putting the first two wheel assemblies together with a castor wheel.  It proved to be informative to see how the components work together before we got too much further into the project.

The first work session was marred by a minor miscommunication about the Raspberry Pi intended to be used as the brain of the chassis. As a short-term substitute, a small and light (and old) Dell laptop was taped on to the chassis to obtain some initial data.

We could drive the test chassis around, but gearbox friction continues to be a problem. We had hoped the real physical load would add some momentum and inertia to the system and smooth things out. This didn’t pan out and we frequently encounter jerky motion of the robot. Our RoboClaw was constantly fighting to keep the motion smooth as it ramped the power up and down to grind through rough spots in the gearbox.

At this point the test chassis has been the focus of two work sessions. The second round included the Raspberry Pi that was originally intended. The motor motion, unfortunately, remained rough. The next effort will try to increase gear lash in the planetary gearbox. We’ll end up with more backlash in the system, something that might be problematic when it is compounded across six wheels, but nevertheless we hope it will prove to be a good trade-off.