One of the great advantages of being a working robotics company with a shipping product and hundreds of active customers is that we get to listen to the marketplace. We have attended Microsoft Build for three years, DeveloperWeek (Austin/SF/NY) for two, and Twilio SIGNAL for one. We’ve been the number one (or among the top 10) trafficked booth at many of these events because, well, robots.
Spending this much time with so many budding robot solution builders means we learn a lot about their desires and needs. When it comes to “what will you build” with Misty, a few conversations we have in the marketplace go something like this:
Developer: “Isn’t Misty too low to the ground to be productive?”
MR: “She can see up to 10′ high when standing a few feet away from a wall and looking up, she can navigate many spaces, and you can put a flag on her (like the ones used with recumbent bicycles) for visibility.”
Developer: “Hmmmm…. I can see how that could work, but my use case requires more human contact, and the humans are standing in the environment — so, more interactions at eye level.”
MR: “You can put her on a desk, table, credenza.”
Developer: “But then she can’t move freely around the space.”
MR: “You’re right; seems like we’re a bit stuck.”
Developer: “How much weight can Misty pull around?”
MR: “About a pound or two — enough for a six-pack of beer, a stack of envelopes, or other small payloads.”
Developer: “So…not capable of pulling 50 to 100 lbs? Or 200 lbs?”
All of which got the inventive engineers at Misty Robotics thinking about how we could take advantage of all of the intelligence in Misty, while creating an opportunity for developers to experiment with a much wider range of use cases. In turn, that led to Robo-Chariot.
In building Robo-Chariot, the engineering team considered a few key facts about Misty. Almost all of the robot’s intelligence – the self-driving, the voice interaction, the facial detection & object recognition, the personality, and the hardware extensibility – is contained in, on, or near Misty’s head. In fact, the only core aspect of Misty’s base is the system responsible for her smooth locomotion.
At companies past (Sphero), the engineering team had replaced one motor control with another, one battery with another, to create a huge robot ball , and so we had some prior experience with transferring most of the capability out of one locomotion system and into another. All of which lead our engineers to wonder, “How quickly and how affordably could we build different locomotive platforms for Misty?”
Answer: not long. It took less than two weeks for our mechanical engineering brains to conceive of and construct a “lift kit” for Misty, raising her to eye-level heights and still allowing Misty to drive with 100% of the existing Misty API set and associated SDK tools.
Robo-Chariot, piece by piece
We’ve long wanted to see whether we could leverage off-the-shelf tool batteries (like the DeWalt battery shown in the images for this post), and to experiment with different motors. Let’s take a deeper dive into what we built:
• Locomotive base: In changing the form factor for the robot, we wanted flexibility to experiment. We selected dense, castor-like wheels so that the chassis would support any reasonable amount of weight we’d need during prototyping. We also chose a pair of high-ratio DC motors, so that we’d have enough torque to accommodate a modest payload, and could move slowly enough to be precise. Finally, we connected the output from the motor to the wheel through a link chain and pair of sprockets. Given the sprockets, chain, and gear motor, we have plenty of flexibility in determining the torque and speed of the chariot.
• Chassis: Flexibility remained at the top of our minds in building the chassis, which led us to choose 8020 aluminum. 8020, while somewhat expensive, offers the advantage of being a material you can order in precise dimensions, and provides ample slots for attaching additional devices. Rather than drilling and screwing pieces together, we used rail anchors and bolts to assemble the pieces. The result is a chassis that is suitably rigid, without compromising our ability to reconfigure it if we need to. We built the upright section of the chassis to raise Misty to around 48”, but because we made it from 8020, we could have selected any reasonable height. If we were certain that we needed a specific height or dimension, or if we were interested in making something less expensive, we could have fabricated the chassis from medium density fiberboard (MDF), cutting, drilling, and glueing each piece in place. In this case, the center of gravity and payload capacity would have been different, and we may have wanted to add ballast to the base to provide some additional stability.
• Control system: The control system consists of two main components. The first is an off-the-shelf motor control board. There are many available; we chose one that matched the stall current for the motors, and could be interfaced via Misty’s UART connection. We used tools directly from the manufacturer’s website to select and flash the control system on the control board. On the software side of Misty, we created a skill that receives standard driving commands from Misty’s API, formats them for the new motor controller, then sends them via the UART connection. We also disabled Misty’s cliff sensors (via software) so that the robot wouldn’t be fooled into thinking it’s about to drive off of an edge.
• The results: With this implementation, we got something very different from Misty. We managed to retain the robot’s intelligence, industrial design, and the existing ecosystem of skills, all while adding a payload-carrying capacity and vertical height. As implemented, this version moves very, VERY slowly, but it can easily be configured to move faster. A human can stand on the chassis (we tested with an engineer) while the robot is driving, and the platform can carry one of us without stalling the motors, so it could actually transport some substantial things from one place to another.
• What’s next: This version doesn’t have any meaningful obstacle avoidance. Misty’s range time-of-flight sensors remain enabled, so the robot could detect a wall, but she wouldn’t have any understanding of shorter obstacles at her new height. To help with the obstacle avoidance and complement the onboard mapping system, we would add a small lidar sensor to the chassis. Additionally, it would be nice to create an enclosure mechanism for the electrical and mechanical components, so that they aren’t visible and have a lower risk of ingesting some of the surrounding environment (like, say, someone’s fingers).
Which brings us to today
After building this new locomotive platform, we asked ourselves, “OK: so what do we do with Robo-Chariot now?”
We knew, as a small company, we weren’t going to just leap into the process of “productizing” such an item . That would be inconsistent with the Lean and Agile principles that have driven our product from the beginning. And we also knew that the likelihood of different use cases requiring different physical configurations is quite high (different heights, different payloads, ability to carry something vs. not, etc). Lastly, we know that our customers’ standard process is to begin with a hypothesized use case, then begin experimentation into that use case by building their robot application, and finally to deploy market trials of those solutions into their hypothesized marketplace. We suspect that each customer may want to minimize the amount of up-front investment into a different locomotive form factor (while maximizing their ability to experiment) both during their development cycle and during their market-testing cycle.
All of which led to one simple conclusion: “Let’s release the blueprints for Robo-Chariot as-is, and then help each customer customize their own locomotive platform to their individual situation.” Now that we know how simple, affordable and straightforward it is (less than 3 man-weeks of effort and less than $1K bill of materials), it’s easy to evaluate a variety of use cases – be they carrying use cases (hospitals, hotels, offices, even small warehouses) or be they human-interaction use cases (retail, restaurants, security/patrol).
So, this week we’re releasing an early version of the guide to build Robo-Chariot, to increase the diversity of use cases our customers can experiment with, to enable us to have conversations with our customers about how they can get customized locomotive solutions built for their use case, and to expand the universe of potential uses for Misty. We invite you to download the guide and BOM, or contact us to have conversations about your use case(s) and customized locomotive platforms that you might want to experiment with.