SGVHAK Rover (and Predecessor) at SCaLE 16x

Friday, March 2nd, 2018. SGVHAK Rover made its public debut on the exhibition floor of SCaLE 16x. It participated in the SGVLUG booth advertising the entire family of SGVLUG and related groups including SGVHAK. It was good to have a deadline to motivate progress on the rover project and it’s even better to have successfully met it.

We also inadvertently lived up to the “hack” part of the name with the corner steering servo hack on the front right wheel. It was not part of the plan but an amusing coincidence. Given that we still had the weak gearbox on the remaining three wheels, we weren’t very keen to hand control over to random visitors at the booth. We did run it around the floor and learned a few things about operating it in such an environment.

The most unpleasant aspect is the crowded RF spectrum. With so many booths filled to the brims with electronics, the wireless signal spectrum is just as crowded as the physical isles. Rover communication between the Raspberry Pi and the operator was occasionally unreliable and we frequently had to react to missed commands. Every page on the rover UI had a big red “Stop Motors” buttons and there were times we kept smashing that button continuously, desperately trying to get that command through, before the rover finally stopped. We’ll have to figure out a fix later.

On Saturday, the JPL team in charge of the baseline rover design stopped by SCaLE for their own public relations demonstration purposes. We had a brief few minutes where both rovers were running around side-by-side. It was fun to compare and contrast the places where two rovers differed, both intentionally and not.

SCaLE_DualRover

SGVHAK Rover Steering Restored with Servo Hack

At the SGVHAK meet a week before SCaLE, the rover ran around for the first time in a public-facing configuration. It was a trial run to see how it would do, and we managed to expose a weakness in the corner steering motor gearbox. With a broken gearbox, the rover is crippled. We have the option to just drag the uncooperative wheel along, as JPL did for their Mars rover Spirit. (It’s even the same location: right-front wheel.) But since it is accessible on a workbench instead of on another planet, we should try to fix it.

Here were our thoughts on the motor:

The most obvious solution is to replace the broken unit with another identical unit, which we are not going to do because this gearbox has already proven itself to be too weak to handle the job. Instead, we’re going bigger: replace with a unit rated to handle more torque. This solution has a few concerns: the first is that it increases cost of rover design, the second is we still have nothing to absorb sharp shocks to the system. We can only “go bigger” for so long.

The third and most critical concern is time. We had wanted to demonstrate the rover running around at SCaLE 16x but the shipment of upgraded gearmotors won’t arrive in time. We need a short-term solution that we can build with what we have on hand, and the best candidate in the here-and-now parts pile are remote control hobby servos. Hacking a steering fix with servos serve two purposes: First, we hope it gives us a drivable rover by SCaLE. Second, it tests an idea that’s been kicked around.

Using remote control hobby servos to steer has the potential to reduce both rover parts count and cost. And devices called “servo savers” are an established solution from the remote control vehicle world to absorb sharp shocks to a steering the system. It’s something promising to investigate and, with a broken gearbox and a deadline, we have motivation to do so.

An evening of resourceful fabrication using parts already on hand results in a jury-rigged servo mounting bracket that lets us steer the wheel until replacement motors show up. This configuration, with a servo handling one of the corner steering duty, was what we ran around at SCaLE and it worked really well. In fact, this corner survived the abuses of the weekend better than the others! With this hack’s success, we contemplate a future rover variant focused on servo motion.

Rover Servo Steering Hack

SGVHAK Rover’s First (Brief) Drive Session

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.

Ginko driving

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.

Chipped Tooth

SGVHAK Rover Systems Integration Test

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.

WheelsRolling

Structure and Wiring Work Still To Be Done

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.

Wiring cleanup

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.

Rover Standing On Its Own Wheels

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.

Rover on 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.

Making Rover Legs Stronger

One of the main objectives of the 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 the 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.

Steering Shaft

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.

Spacer

Spacer installed

Rover Frame Assembly

The SGVHAK rover wheels were a deviation from the baseline design, hence that’s where we started to get an early lead on any problems. As the baseline design is already proven, that started 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.

Frame Assembly Underway

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.

Wheel Assembly Underway

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.

Staying Centered is Hard

Adventures in Manually Tuning RoboClaw PID

Encoder Wheel UpgradeIncreasing 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.

Spring 2018 Brewery Art Walk

This weekend’s Brewery Art Walk was my first visit to the facility. I arrived to find a larger campus of artist lofts, roughly half of which were open for event visitors. I aimed to find artworks that are beyond the typical flat two-dimension works so in the interest of time I skipped most studios of painters and photographers.

The reason I even knew about the event was because a member of Two Bit Circus advertised the event (and their participation in it) during lightning talk segment of Hackaday LA’s March meet. So my first stop was the exhibit room for Two Bit Circus.

Their subtitle was “Engineering Entertainment” and all exhibits certainly fit the bill. Here’s one installation called the Ledge, where the customer dons an Oculus Rift headset showing footage of riding a window-cleaner’s platform up the side of a high-rise building. The illusion is enhanced by the platform, which was motorized to give a wobbly sensation. As far as I can determine the wobbling pattern is fixed and has no correlation to the visual motion.

Two Bit Circus - Ledge

I had hoped to get a view of the workshop area as well, but that was not open for visitors. All we got to see was the nifty entrance. The hand crank to the right of the door turns the gears and chains of the sign over the doorway.

Two Bit Circus - Workshop

Facing this door is a cellular radio tower wearing a palm tree disguise.

Cell tower palm tree

Walking into the loft of Dystopian Studios will transport you into a space fully implementing the aesthetic of a dystopian future. The space itself was as much a work as the individual pieces on display. The area which caught my attention was a collection of Nerf guns (some of which overlap with my collection) modified to fit with the Dystopian Studio theme.

Dystopian Studios Nerf.jpg

On the theme of artists applying their art to their space, Bruce Gray‘s studio was not open for visitors but there was enough visible for me to see he’s given his air compressor the Charlie Brown treatment.

Bruce Gray air compressor

One of the studios had a machine outside blowing soap bubbles filled with smoke. The space appears to be full of clothing creations. Personally I would have found it far more interesting if the whole space were dedicated to novel mechanical contraptions like smoke bubble machines.

Smoke Bubbles

I had expected to find a few kinetic art studios and was not disappointed when I found William Sandell’s Kinetic Assemblage.

William Sandell Kinetic Assemblage

On a larger scale, Richard Wilks studio had a few items on display. Inside the studio is a work in progress making a spinning metallic sculpture that aims to evoke the fluid motion of a jellyfish. The white wheel on the right is a prototype for visualizing motion before they are built out of metal.

Richard Wilks jellyfish

Parked outside their studio entrance is the Aquatrope. It is the type of work I expect to find at Burning Man and several pictures shown adjacent to the piece imply that’s exactly where it has gone.

Richard Wilks Aquatrope

The highlight of today’s visit was finding Sean Sobczak’s Sandman Creations studio. These sculptures made of welded segments of wire is an impressive level of sculpting beyond working in solid media. It’s not simply a wire mesh like the 3D data in a computer: the wires serve an aesthetic purpose in addition to their structural requirement. Sometimes they trace out surface features of the subject, sometimes they flow and move on their own path.

Sobczak Sandman Creations dreams

Many of the pieces on display feature strings of lights inside the skeleton and a fabric wrapping the metal on the outside.

Sobczak Sandman Creations octopus

Sadly photographs do not do these pieces justice, so full appreciation requires enjoying the work in person. Which I plan to do again in about six months! (Assuming the studio is open for Fall 2018 Brewery Artwalk.)

 

Tiny Increase In Wheel Hub Gear Lash Gave Huge Increase In Usability

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!

Wheel-Rotation

Test Chassis With Two Wheel Differential Drive

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.

Test Chassis with Dell

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.

Test Chassis with Pi

Encoder Fixed, Manual PID Tuning Begins

The jagged wave form of the encoder signal was diagnosed to the plastic filament used to print the encoder wheel. It was opaque to visible light but the infrared light used by the optical encoder could penetrate enough to trigger false transitions. Reprinting the encoder wheel with a different plastic resulted in clean encoder square wave form confirmed under an oscilloscope.

The planetary gear updated with the encoder is unfortunately correlated with a new problem: the automatic PID tuning algorithm in Ion Studio stopped working. Whenever the tune button was pressed, a few motor movements would occur in the first half second or so, then the software freezes up. Status LED on Roboclaw stopped blinking, confirming that communication between the software and the control board broke down. The motor continued spinning according to the last instruction it received. Terminating Ion Studio was not enough to release the serial port and Windows had to be rebooted. A reset of the Roboclaw back to factory configuration did not change this behavior, nor did switching to another Windows machine with Ion Studio.

An Ion Motion Control forum post implied a faulty encoder could cause this problem, but the encoder looks good to us under the oscilloscope. With little other information to diagnose with, we had to fall back to manual tuning of the PID control loop. This is a common task in building motion control systems, with scholastic research on how to obtain the best values. But with some basic understanding of PID control it’s possible to manually get close enough to proceed with the project.

RoboClaw Test Setup

A challenge of tuning PID systems comes from the fact the values have no standardized units. A good proportional (P) gain might be 6.0 in one PID system and another system would want 400. Ion Motion Control documentation for Roboclaw didn’t seem to have any guidelines on the number range we should expect to use, just that each value in the API is represented by a 32-bit integer.

The default values on a freshly reset Roboclaw is zero, which is obviously not going to work. Lacking any guidance, we started with setting proportional gain (P) to one and left the rest at zero. This took several seconds to start turning the wheel. Setting P to ten, then 100, increased the response rate. At 1000, we saw oscillation of the motor as it raced too far ahead, then backtracked too far, then forward too far again. This is a symptom of P set too high, so this gives us a starting range of somewhere in the hundreds.

The freshly 3D-printed planetary gears added an unforeseen challenge. They have yet to wear in to each other and still have some rough spots. Combined with a tight fit (by design, to minimize backlash) this translated to high stiction requiring more power sent to the motor before it would start turning. At the moment, the wheel is spinning in open air and required little power to keep turning once it started. The large difference between startup power vs. runtime power translated to a tendency to overshoot on startup. This behavior is visually similar to a too-large P value and hard to tease them apart when tuning manually.

A well-tuned PID control system could handle this properly, but we’re not there yet. In the short term, the plan is to put these wheels on a test chassis so we could see how it works as actual propulsion. Also, installing the wheel on a chassis (and putting a workload on it) would increase the power needed to keep the wheel turning. Narrowing the difference between startup power and runtime power will hopefully help make fine-tuning the control loop easier.

Rover Wheel’s First RoboClaw Test Run Foiled By Encoder

Once we had all the parts of our 3D-printed rover wheel we assembled the first prototype. Then we brought it to one of our local makers’ SGVHAK meetup and hooked it up to a RoboClaw motion controller. The first half of the night was spent figuring out the computer software end of things. The RoboClaw configure software “Ion Studio” is Windows-only, whereas the Python software on hand is expected to run on a Linux distribution, most likely Ubuntu.

The software configuration settled on Windows running Python code inside WSL. (Windows Subsystem for Linux.) Python inside WSL couldn’t access the USB serial port unless given superuser privileges. (UPDATE: Should have tried adding user to dialout group.) Not ideal, but enough to get us going. Also worth mentioning: the two pieces of software (Ion Studio and Python) are unable to share the port. One must be shut down before the other could gain access to the port. Once all the above were squared away, we could send commands to RoboClaw from Python command line and commence the second half of the night: learning how to control wheel motion with RoboClaw.

The motion we saw was rough. Some of it could be attributed to the imprecision of 3D printed parts. But we suspected something else contributed to the jittery motion we saw. We suspect the PID tuning is far off the mark, and the acceleration / deceleration numbers are not the best. But the root culprit was traced down to the square wave signal from the optical encoder. We need the signal to be a clean square wave before any of those other tuning parameters could function reliably. Hooking the encoder output pins to an oscilloscope showed a ragged signal that would mislead the RoboClaw as to the physical movement of the assembly. It’s pretty hopeless to try tuning the other parameters without accurate motion feedback.

Bad Encoder Waveform

The encoder signal will need to be fixed before we come back to PID tuning & friends.

Our prime suspects for causing this waveform are:

  1. Poor electrical connection
  2. Insufficient power delivered to the IR emitters in the encoder.
  3. Problem with the 3D-printed slotted wheel.

SGVHAK Rover Mentioned By Pasadena Now

pasnow-caltech-03The rover made an appearance in the local news Pasadena Now as picture #3 in the photo gallery. (As did I, though I was not named and the picture only shows me from mid-torso down.) It’s cool to see that the local newspaper editor looked over their pictures of Caltech’s Science for March event this past weekend and chose the rover as one of the top ten to include in the gallery.

I think I even remember this photographer. (People wielding SLR cameras are few and far in between in this day of cell phone cameras.) I’m a little sad we didn’t speak, which resulted in the wildly inaccurate photo caption. I didn’t get to promote the JPL Open Source Rover project, nor SGVHAK’s role in beta testing the build instructions. Oh well.

The NASA stickers on the wheels serve a functional purpose: since the rover will be running on dirt and grass, we risk contamination and possible jamming if any debris got into the open faced planetary gearbox. The most convenient wheel cover turned out to be NASA stickers handed out by another booth. It’s almost the right diameter and a perfect fit for our mars rover inspired robot project.

Rover Begins With Wheel Assembly

Back when the SGVHAK rover started, we started literally from the ground up by building the wheels. The wheels were one of the more significant differences from the baseline rover design and we wanted to get a head start on problems.

Once the initial parts of the planetary gear hub for rover wheel were 3D printed, we started to get an idea of how well things fit our target design constraints: All of the 3D printed parts must fit between two non-3D printed components. On the outside: the tire (and foam tire insert) of a remote control monster truck. On the inside: an electric motor.

Wheel Hub

The space constraints pointed us towards a planetary gear as the best approach for the reduction gear in this drivetrain. In addition to the planetary gears, the space must accommodate the components for a rotary encoder so we can set up a closed loop motion control system for wheel motion. We don’t just want the wheel to turn – we want it to turn at specific rates, to reach specific positions, and we need an encoder to close the feedback loop on what the wheel is actually doing.

Planetary Gear

Once all the mechanical bits are assembled, it will be time to hook it up to the motion control circuit. We’ll be using RoboClaw boards from Ion Motion Control for this project.

SGVHAK Rover at Caltech Science for March

Caltech QuadSGVLUG has a booth at Caltech’s Science for March event which means another public outing for SGVHAK Rover. The event itself featured a lot of groups affiliated with Caltech showing what they have offer to the visiting public. The weather cooperated with a nice sunny day for people to stop in for a look.

Pasadena City College, which is basically next door, had a strong presence with many student groups showing off their projects. Here’s a machine that takes poker chips in a chute (right) and sorts them by color into bins (lower left).

Poker chip sorter

JPL brought in some model rover wheels. These were not made with the same material of real rover wheels, but they are actual size. They represent the wheels of Sojourner, the Spirit/Opportunity twins, and Curiosity rover.

Rover wheels actual size

Our SGVHAK rover started the day sitting on the table.

Rover on table

But it didn’t take long before the rover hit the road and started demonstrating its chops by climbing some bricks.

Rover Brick Demo

A demonstration of suspension capability is to sit down in front and let the rover climb over your legs. One of the times this was demonstrated, it caught the attention of a bunch of children who ran and lined up to be run over too.

Kids lining up to get run over

All this climbing was great, but it took a toll on the rover. The stresses started loosening up some screws and the right-front wheel started dangling on one final loose screw.

Rover Wheel Dangling

Rover Wheel Last Screw

A little field repair was in order – stealing screws from elsewhere on the rover to get it back up and running again.

Rover Wheel Field Repair

Upgrading M.2 SSD on Luggable PC

When Luggable PC Mark II was constructed in Fall 2017, the industry was experiencing a shortage of flash memory. Most of the fabrication facilities were switching to over to make the next generation “3D NAND” flash, following the lead of industry leaders like Samsung who got their 3D NAND flash up and running first. Taking fabs offline meant a shortage in supply and, with the technical glitches that always come with a big upgrade, the shortage in supply started driving prices upwards.

Industry news sources estimated the supply crunch will ease sometime around first quarter of 2018. So used a 256GB M.2 SSD already on hand for the project expecting to upgrade later. Well, it’s the end of 1Q2018 and prices have indeed started dropping. 256 was getting awfully cramped so even though prices are likely to drop further, today it has dropped enough for impatience to win out. Time to double the capacity with a WDS500G2B0B.

This is a unit from Western Digital’s Blue line, the economy alternative to their high performance Black line. From a technical perspective, the biggest differentiation is the NVMe interface used in the Black line. We won’t get top of the line performance with a Blue drive, and ~500GB can still feel cramped at times, but it’s enough elbow space while we wait for 1TB NVMe 3D NAND SSD prices to drop. (That’s a lot of acronyms all strung together…)

The Luggable PC chassis was originally designed for easy SSD replacement by cutting an access port in the back plane to make SSD accessible by removing the monitor. Unfortunately, complications were found after assembly, requiring extra clamps to keep the monitor in place. Which sadly also made it much more difficult to remove, defeating the purpose of the access port. We’re back to plan A, removing motherboard to replace the M.2 SSD underneath.

Four screws were removed so we could lift the center panel.

1 - Center panel removed

Taking a good look at the insides, we see that one of the monitor mounting screws has gone AWOL. We’ll have to replace it during re-assembly.

2 - screw missing

After the wireless network cables were detached, along with the four motherboard mounting screws, carefully lifting the motherboard exposed the M.2 SSD underneath for replacement.

3 - SSD accessible

With the SSD upgraded, the biggest remaining pain point is the old GPU. We’ve waited six months for the 3D NAND transition to ramp up and drop SSD prices. We’re still waiting for the cryptocurrency fad to blow over so we can get a reasonably priced GPU…

(Cross-posted to Hackaday.io)

Resolving Plex Update Failure in FreeNAS Jail “repository FreeBSD contains packages for wrong OS version”

plex-logo-e1446990678679I’ve been happily running Plex in a FreeNAS (FreeBSD) Jail for a while, picking up the periodic updates via “pkg update”. But now there’s a snag. Apparently a breaking change was introduced in a recent FreeNAS update and now binaries in the old jail are out of sync with the underlying operating system. The visible symptom is the following error message trying to run pkg update.

pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:11:amd64
Processing entries: 100%
Unable to update repository FreeBSD  
Error updating repositories!

Thankfully we get a detailed and specific error message. A web search using that error output found this discussion thread on FreeNAS user forums, which points to ixsystems issue tracker #27904. Reading the information, this break is not considered a bug in FreeNAS that will be fixed. Instead, the onus is on the user to manually update the jail (pointing to this page on how to do so) or to create a new jail.

After reading over the instructions on updating a jail, it seems easier to create a new jail and migrate my Plex server over to the new instance. None of the media need to be moved because they were a read-only mapping between directories on NAS volume and jail running Plex. It is simple to recreate the mapping after following FreeNAS manual for creating a new jail.

The only parts that needed moving were Plex server’s internal data, which Plex has documented here. Thankfully there are no tricky database operations involved – it is a straightforward copy operation to transfer from the old jail to the new one.

Once the new jail completed running pkg install plexmediaserver, a quick browse through Plex library seems to show everything is in order. The old Plex jail will be kept around in a non-running state for a while, just in case there’s something left behind in the move that we might want retrieve later.

Someone Put a USB Plug Inside a USB Plug

Today we point our spotlight at one method of supporting multiple USB plug form factors in the most compact layout possible: putting a (micro) USB plug inside a USB (type A) plug. It doesn’t look terribly robust or reliable for the long term, but it is indeed extremely compact and clever in its own Rube Goldberg way.

Gigastone 32GB USB Contraption

The mechanical engineer who devised this contraption took advantage of the fact a micro USB plug’s entire outer dimension is physically smaller than the “tongue” part of a USB type A plug. And conveniently, all the pins are electrically identical so they are easy to route. From there it’s a matter of creating the small sheet metal hinge for the exterior surround of type A portion of the plug so the user can swing it out of the way and expose the micro USB plug embedded within.

Usually smaller flash memory brands assemble their product from spot market purchases and other similar existing large volume products. Gigastone is not one of the bigger names.  Given this, the initial assumption (fair or not) was that this plug is a catalog item somewhere. But if so, it’s not obviously available from Digi-Key or Mouser.

Given the lack of immediately obvious source, we’ll tentatively assign credit for this clever design to Gigastone and their team behind this particular flash drive. Good job, guys, this item’s cleverness managed to stand it out amongst the crowd of commodity flash drive offerings.