Mars-Bound Rover Perseverance

NASA has just announced the winner of their Name the Rover Contest: Perseverance. The contest invites K-12 students within the United States to submit names for the Mars 2020 rover along with an essay explaining why it is the best name. Sadly, not one of them suggested naming Mars 2020 rover “Sawppy” but I’ll just have to get past that personal disappointment somehow.

I’ve already seen a few people calling it “Persie”, “Percy”, and variants thereof. The official Twitter handle is @NASAPersevere and judging by the first few tweets, this account will follow the trailblazing Phoenix PR effort and tweet from the first person. I’m doing the same for Sawppy, and @SawppyRover has followed @NASAPersevere for future updates. If all goes well, Perseverance wouldn’t even be the only Mars-bound robotic explorer: the European Space Agency has designed one of their own. ExoMars 2020 is an interesting engineering marvel in and of itself, but that’s for another blog post.

Back to the naming contest: I really like the cartoony rover they used. I’ve spent a lot of time analyzing photos, videos, and CAD models of Curiosity and Mars 2020 Perseverance when building Sawppy. I see a lot of technical accuracy represented in the illustration. From the robot arm joints to the rocker-bogie suspension components, I’m very impressed at how well it blends technical details with classic cartoon techniques for appealing character animation. I’m definitely keeping this guy in mind for my future rover work.

In the meantime I have to get on various parts of Sawppy’s online documentation and update mentions of Mars 2020 to Perseverance. I’ll definitely update greeting pages, but I probably won’t bother to update every past project log. The rule of thumb: If it has a date, people can tell it was written before the announcement, so I will probably let it slide. If it doesn’t have a date, I should probably fix it.

Preparing For ROS 2 Transition Looks Complicated

Before I decided to embark on a ROS Melodic software stack for Sawppy, I thought about ignoring the long legacy of ROS 1 and going to the newer ROS 2 built on more modern infrastructure. I mean, I told people to look into it, so I should walk the walk right? Eventually I decided against putting Sawppy on ROS 2, the deal breaker was that the Raspberry Pi is not a tier 1 platform for ROS 2. This means there’s no guarantee on regular binary releases for it, or that it will always function. I may have to build my own arm32 binaries for Raspbian from source code, and I would be on my own to verify functionality. I’ve done a superficial survey of other candidates for a Sawppy brain, but for today Sawppy is still thinking with a Raspberry Pi.

But even after making that decision I wanted to keep ROS 2 in mind. Open Robotics has a  ROS 2 migration guide for helping ROS node authors navigate the transition, and it doesn’t look trivial to me. But then again, I don’t have the ROS expertise to accurately judge the effort involved.

The biggest headache for some nodes will be the lack of Python 2 support. Mainly impact ROS nodes with a long legacy of Python 2 code, it does not impact a new project written against ROS Melodic which is supposed to support Python 3.

The next headache is the fact that it’s not possible to write if/else blocks to allow a single ROS node to simultaneously support ROS 1 and 2. The recommendation is to put all specialized logic into generic non-ROS-specific code in a library that can be shared. Then have separate code tailored to the infrastructure paradigms of ROS and ROS 2. This way all the code integrating with a ROS platform can be separated, but calling into a shared library.

And it also sounds like the ROS/ROS 2 build systems conflict so they can’t even coexist side by side at the same time. Different variants of a node have to live in separate branches of a repository, with the shared library code merged across branches as development continues. Leaving ROS/ROS 2 specific infrastructure code live in their separate branches.

I can see why a vocal fraction of ROS developers are unhappy with this “best practice”. And since ROS is open source, I foresee one or more groups joining forces to keep ROS 1 alive and working with old code even as Open Robotics move on to ROS 2. Right now there are noises being made from people who proclaims to do a similar thing, saying they’ll keep Python 2 alive past official EOL. In a few years we can look back and see if those Python 2 holdouts actually thrived, and we can also see how the ROS 1/ROS 2 situation has evolved.

Wish List: Modular Sawppy Motor Controllers

One of the goals for my now-abandoned ROS Melodic Sawppy software project is something I still believe to be interesting. In contrast with the non-rover specific goals I outlined over the past few days, this one is still a rover item: I would like Sawppy motor control to be encapsulated in modules that can be easily swapped so Sawppy siblings are not required to use LX-16A servos.

My SGVHAK rover software had an infantile version of this option, and it was written in extreme time pressure to support our hack of using a RC servo controller to steer the right-front corner during SGVHAK rover’s SCaLE debut. In SGVHAK rover software, all supported motor controller code are all loaded, an unnecessary amount of complexity and overhead. It would be nice for a particular rover to bring in just the code it needed.

The HBRC crew up in the SF Bay Area (Marco, Steve, and friends) have swapped out the six drive wheels for something faster while keeping the servos for steering, so a starting point is to have options for different controls for steering and driving. But keeping in mind the original scenario was using a RC servo to hack a single steering corner, we want to make it possible to use heterogeneous motor controllers for each of ten axis of motion.

I need to better understand Rhys code to know if this is something I can contribute back to the Curio ROS Melodic software project. Rhys has stated an intent to bring in ros_control for Curio software stack. Primarily for the reasons of better Gazebo simulation, but it would also abstract Sawppy motor control logic: generic velocity controllers for driving wheels and position controllers for steering. And from there, we can have individual implementations responding to those controllers. Is that how it will work? I need to ramp up on Gazebo and ros_control before I can speak knowledgeably about it.

Learning Github Actions For Automating Verification

Once I wrote up some basic unit tests for my Sawppy rover Ackermann math, I wanted to make sure the tests are executed automatically. I don’t always to run the tests, and a test that isn’t getting executed isn’t very useful, obviously. I knew there were multiple tools available for this task, but lacking the correct terminology I wasted time looking in the wrong places. I eventually learned this came under the umbrella of CI/CD tools. (Continuous integration/continuous deployment.) Not only that, a tool to build my own process has been sitting quietly waiting for me to get around to using it: GitHub Actions.

The GitHub Actions documentation was helpful in laying out the foundation for me as a novice, but I learn best when the general foundation is grounded by a concrete example. When looking around for an example, I realized again one was sitting right in my face: the wemake Python style guide code analysis tool is also available as a prebuilt GitHub Action.

Using it as a template, I modified my YAML configuration file so it ran my Python unit tests in addition to analyzing my Python code style. And that it would do this upon every push to the repository, or whenever someone generates a pull request. Now we have insight into the condition of my code style and basic functionality upon every GitHub interaction, ensuring that nobody can get away with pushing (or create a pull request) with code that is completely untried and fundamentally broken. If they should try to get away with such a thing, GitHub will catch them doing it, and deliver proof. It’s not extensive enough to catch esoteric problems, but it provides a baseline sanity check.

I feel like this is something good to keep going and put into practice for all my future coding projects. Well, at least the nontrivial ones… I’ll probably skip doing it for simple Arduino demo sketches and such.

First Foray Into Python Unit Tests

When a Sawppy community member stepped up and released a ROS Melodic rover software stack, I abandoned my own efforts since there was little point in duplicating effort. But in addition to rover control, that project was also a test run for a few other ideas. I used a Jupyter notebook to help work through the math involved in rover geometry, and I started using a Python coding style static analysis tool to enforce my code style consistency.

I also wanted to start writing a test suite in parallel to my code development. It’s something I thought would be useful in past projects but never put enough focus into it. It always seemed so intimidating to build test suites that are robust enough to catch all the bugs, when it takes effort to climb the learning curve to even verify the most basic functionality. What would be the point of that? Surely basic functionality would have been verified before code is pushed to a Github repository.

Then I had the misfortune to waste many hours on a different project, because another developer did not even verify the code was valid Python syntax before committing and pushing to the repository. My idealism meant I wasted too many hours digging for another explanation, because “surely they’ve at least ran their code” and I was wrong. This taught me there’s value in unit tests that verify basic functionality.

So I brought up the Python unit test library documentation, and started writing a few basic tests for rover Ackermann geometry calculation. The biggest hurdle was that binary floating point arithmetic is not precise enough to use the normal equality comparison, and we don’t even need that much precision anyway. Calculating Sawppy steering geometry isn’t like calculating orbital trajectory for an actual mission to Mars. For production code using Python 3.5 onwards, there’s a math.isclose() available as a result of PEP 485. And for the purposes of Python unit tests, we can use assertAlmostEqual(). And how did I generate my test data? I used my Jupyter notebook! It’s a nice way to verify my wemake-compliant code would generate the same output as the original calculations hashed out in Jupyter notebook.

And finally, none of this would do any good if it doesn’t get executed. If someone is going to commit and push bad code they didn’t even try to run, they’re certainly not going to run the unit tests, either. What I need is to learn how to make a machine perform the verification for me.

Reworking Sawppy Ackermann Math in a Jupyter Notebook

The biggest difference between driving Sawppy and most other robotic platforms is the calculation behind operating the six-wheel-drive, four-wheel-steering chassis. Making tight turns in such a platform demands proper handling of Ackermann steering geometry calculations. While Sawppy’s original code (adapted from SGVHAK rover) was functional, I thought it was more complex than necessary.

So when I decided to rewrite Sawppy code for ROS Melodic (since abandoned) I also wanted to rework the math involved. I’ve done this a few times, most recently to make the calculations in C for an Arduino implementation of Sawppy control code, and it always starts with a sketch on paper so I can visualize the problem and keep critical components in mind.

Once satisfied with the layout on paper, I translate them into code. And as typically happens, that code would not work properly on the first try. The test/debug/repeat loop is a lot more pleasant in Python than it was in C, so I was happy to work with the tools I knew. But if the iterative process was even faster, I was convinced I could write even better code.

Thus I had my first real world use of a Jupyter notebook: my Sawppy Python Ackermann code. I could document my thinking in Markdown right alongside the code, and I could test ideas for simplification right in the notebook and see their results in numerical form.

But I’m not limited to numerical form: Jupyter notebooks can access a tremendous library of data visualization tools. It was quite overwhelming to wade through all of my options, I ended up using matplotlib‘s quiver plot. It plots a 2D field of arrows, and I used arrow direction to represent steering angle and arrow length to represent rolling speed. This plot gave a quick visual confirmation those numbers made sense.

In the Jupyter notebook I could work freely without worrying about whether I was adhering properly to style guides. It made the iterative work faster, but that did mean spending time to rework the code to satisfy wemake style guides. The basic logic remains identical between the two implementations.

I think this calculation is better than what I had used on SGVHAK rover, but it feels like there’s still room for improvement. I don’t know exactly how to improve just yet, but when I have ideas, I know I can bring up the Jupyter notebook for some quick experiments.

Inviting wemake to Nitpick My Python Code Style

I’m very happy Rhys Mainwaring released a ROS Melodic software stack for their Curio rover, a sibling of my Sawppy rover. It looks good, so I’ve abandoned my own ROS Melodic project, but not before writing down some notes. Part 1 dealt with ROS itself, many of which Rhys covered nicely. This post about Python Style is part 2, something I had hoped to do for the sake of my own learning and I’ll revisit on my next Python project. (Which may or may not be a robotic project.)

The original motivation was to get more proficient at writing Python code that conforms to recommended best practices. It’s not something I can yet do instinctively, so every time I tackle a new Python project I have to keep PEP8 open in a browser window for reference. And the items not explicitly covered by PEP8 are probably covered by another style guide like Google’s Python style guide.

But the rules are useless without enforcement. While it’s perfectly acceptable for a personal project to stop with “looks good to me” I wanted to practice going a step further with static code analysis tools called “linter“s. For PEP8 rules, the canonical linter is Flake8 which is a Python source code analysis tool packaged with a set of default rules for enforcing PEP8. But as mentioned earlier, PEP8 doesn’t cover everything, so Flake8 has option for additional modules for enforcing even more style rules. While browsing these packages, I was amused to find the wemake Python style guide which called itself “the strictest and most opinionated python linter ever.”

I installed wemake packages so that I can make Python code in my abandoned ROS Melodic project compliant with wemake. While I can’t say I was thrilled by all of the rules (it did get quite tedious!) I can confirm it does result in very consistent code. I’m glad I’ve given it a try, and I’m still undecided if I’m going to commit to wemake for future Python projects. No matter the final decision, I’ll definitely keep running at least plain flake8.

But while consistent code structure is useful for ease of maintenance, during the initial prototyping and algorithm design it’s nice to have something with more flexibility and immediate feedback. And I’ve only just discovered Jupyter notebooks for that purpose.

Original Goals For Sawppy ROS Melodic Project

Since a member of the Sawppy builder community has stepped up to deliver a ROS Melodic software stack, I’ve decided to abandon my own effort because it would mean duplicating a lot of effort for no good reason. I will write down some thoughts about the project before I leave it behind. It’s not exactly a decent burial, but it’ll be something to review if I ever want to revisit the topic.

Move to ROS Melodic

My previous ROS adventures were building the Phoebe Turtlebot project, which was based on ROS Kinetic. I wanted to move up to the latest long term service release, ROS Melodic, something Rhys has done as well in the Curio project.

Move to Python 3

I had also wanted to move all of my Python code to Python 3. ROS Kinetic was very much tied to Python 2, which reached end-of-life at the beginning of 2020. It was not possible to move the entire ROS community to Python 3 overnight, but a lot of work for this transition was done for ROS Melodic. Python 2 is still the official release for Melodic, but they encourage all Python modules to be tested against Python 3 and supposedly all of the core infrastructure has been made to be compatible with Python 3. Looking over the Curio project, I saw nothing offhand indicating a dependency on either Python version, so I’m cautious optimistic it is Python 3 compatible.

Conform to ROS Project Structure

I originally thought I could create a Sawppy ROS subdirectory under Sawppy’s main Github repository, but decided to create a new repository for two reasons:

  1. ROS build system Catkin imposes its own directory structure, and
  2. Existing name “Sawppy_Rover” does not conform to ROS package naming recommendations. Name must be all lowercase to avoid ambiguity between case-sensitive and case-insensitive file systems. https://www.ros.org/reps/rep-0144.html

Rhy’s Curio project solves all of these concerns.

Conform to ROS Conventions

Another motivation for a rewrite of my Sawppy code was to change things to fit ROS conventions for axis orientation and units:

  • Sawppy had been using +Y as forward, ROS uses +X as forward.
  • Sawppy had been using turn angle of positive degrees as clockwise, ROS uses right hand rule along +Z axis meaning counter-clockwise.
  • Math functions prefer to work in radians, but older code had been written in terms of degrees. Going with ROS convention of radians would skip a lot of unnecessary conversion math.
  • One potential source of confusion: “angular velocity” flips direction from “turn direction” when velocity is negative, old Sawppy code didn’t do that.

Rhy’s Curio project appears to adhere to ROS conventions.

All of that looks great! Up next on this set of notes, my original intent to practice better Python coding style with my project.

Rhys Mainwaring’s ROS Melodic Software and Simulator for Sawppy

When I created Sawppy, my first goal was to deliver something that could be fun for robotics enthusiasts to play with. The target demographics were high school students and up, which meant creating a software stack that is self-contained and focused enough to be easy to learn and modify.

To cater to Sawppy builders with ambition for more, one of the future to-do list was to write the necessary modules to drive Sawppy via open source Robot Operating System. (ROS) It is a platform with far more capability, with access to modules created by robotics researchers, but not easy for robotics beginners to pick up. I’ve played with ROS on-and-off since then, never quite reaching the level of proficiency I needed to make it happen.

So I was very excited to learn of Rhys Mainwaring’s Curio rover. Curio is a Sawppy sibling with largely the same body but running a completely different software stack built on ROS Melodic. Browsing the Curio code repository, I saw far more than just a set of nodes to run a the physical rover, it includes two significant contributions towards a smarter rover.

Curio Rover in Simulation

There’s a common problem with intelligent robotics research today: evolving machine learning algorithms require many iterations and it would take far too long to run them on physical robots. Even more so here because, true to their real-life counterparts, Sawppy and siblings are slow. Rhys has taken Sawppy’s CAD data and translated physical forms and all joint kinematics to the Gazebo robot simulator used by ROS researchers. Now it is possible to work on intelligent rovers in the virtual world before adapting lessons to the real world.

Rover Odometry

One of the challenges I recognized (but didn’t know how to solve) was calculating rover wheel odometry. The LX-16A servos used on Sawppy could return wheel position, but only within an approximately 240 degree arc out of the entire 360 degrees circle. Outside of that range, the position data is noisy and unreliable.

Rhys has managed to overcome this problem with an encoder filter that learned to recognize when the servo position data is unreliable. This forms the basis of a system to calculate odometry that works well with existing hardware and can be even faster with an additional Arduino.

ROS Software Stack For Sawppy

Several people have asked me for ROS software for Sawppy, and I’m glad Rhys stepped up to the challenge and contributed this work back to the community. I encourage all the Sawppy builders who wanted ROS to look over Rhys’ work and contribute if it is within your skills to do so. As a ROS beginner myself, I will be alongside you, learning from this project and trying to run it on my own rover.

https://github.com/srmainwaring/curio

(Cross-posted to Sawppy’s Hackaday.io page)

Sparklecon 2020: Sawppy’s First Day

I brought Sawppy to Sparklecon VII because I’m telling the story of Sawppy’s life so far. It’s also an environment where a lot of people would appreciate the little miniature Mars rover running amongst them.

Sparklecon 2020 2 Sawppy near battlebot arena

Part of it was because a battlebot competition was held at Sparklecon, with many teams participating. I’m not entirely sure what the age range of participants were, because some of the youngest may just be siblings dragged along for the ride and the adults may be supervising parents. While Sawppy is not built for combat, some of the participants still have enough of a general interest of robotics to took a closer look at Sawppy.

Sparklecon 2020 3 Barb video hosting survey

First talk I attended was Barb relaying her story of investigating video hosting. Beginning of 2020 ushered in some very disruptive changes in YouTube policies of how they treat “For Kids” video. But as Barb explains, this is less about swear words in videos and more about Google tracking. Many YouTube content authors including Barb were unhappy with the changes, so Barb started looking elsewhere.

Sparklecon 2020 4 Sawppy talk

The next talk I was present for was my own, as I presented Sawppy’s story. Much of the new material in this edition were the addition of pictures and stories of rovers built by other people around the country and around the world. Plus we recorded a cool climbing capability demonstration:

Sparklecon 2020 5 Emily annoying things

Emily gave a version of the talk she gave at Supercon. Even though some of us were at Supercon, not all of us were able to make it to her talk. And she brought different visual aids this time around, so even people who were at the Supercon talk had new things to play with.

Sparklecon 2020 6 8 inch floppy drive

After we gave our talks, the weight was off our shoulders and we started exploring the rest of the con. During some conversation, Dual-D of NUCC dug up an old school eight inch floppy drive. Here I am failing to insert a 3.5″ floppy disk in that gargantuan device.

Sparklecon 2020 7 sand table above

Last year after Supercon I saw photographs of a sand table and was sad that I missed it. This year I made sure to scour all locations to make sure I can find it if it was present. I found it in the display area of the Plasmatorium drawing “SPARKLE CON” in the sand.

Sparklecon 2020 8 sand table below

Here’s the mechanism below – two stepper motors with belts control the works.

Sparklecon 2020 9 tesla coil winding on lathe

There are full sized manual (not CNC) lathe and mill at 23b shop, but I didn’t get to see them run last year. This year we got to see a Tesla coil winding get built on the lathe.

For last year’s Sparklecon Day 2 writeup, I took a picture of a rather disturbing Barbie doll head transplanted on top of a baseball trophy. And I hereby present this year’s disturbing transplant.

Sparklecon 2020 WTF

Sawppy has no idea what to do about this… thing.

Sawppy Servo Experiment: Standard Servo with Metal Horn

From birth my Sawppy has been running around with LX-16A servos made by LewanSoul (also seen sold under the Hiwonder brand *) but that is not an explicit requirement. From the onset I designed Sawppy to accommodate multiple different servo types, primarily the three I investigated. In theory any servo would work, as long as they physically fit within the available space and someone puts in the effort to design a servo-specific mounting bracket and output adapter.

In an exploration to lower cost of rover building, today’s experiment is to validate my design goal of flexibility, putting theory into practice by adapting standard RC servos. This servo was also interesting because it has a metal horn, which would replace the common plastic servo horns that have been a common point of failure. This particular pairing of servo and horn came from now-defunct Roboterra (as of writing, the link shows up as a Squarespace site whose subscription has expired.) But the same concepts should apply to other servos and their horns.

Roboterra servo with metal horn

An adapter bracket was quickly whipped up to bolt to Sawppy. The bracket surrounds the entire perimeter of the servo including the four empty mounting points. The servo is not mounted as RC servos usually are, because Sawppy was designed so the servo only needs to provide twisting force. They are free to slide along axis of rotation, letting 608 bearings built elsewhere into Sawppy take care of handling the forces of a rover on the move.

Roboterra servo bracket and coupler

The metal horn on this servo is much larger in diameter than LX-16A servos, allowing a larger 3D-printed coupler. The metal horn was tapped to accept screws with M3 thread. The larger coupler held with M3 machine screws is far more sturdy than the LX-16A solution of coarse threads cut by self-tapping screws.

This is a promising first step into using commodity RC servos on a rover build. A large selection of RC servos are out there for every budget and power, making them a tempting option for some rover builders. But there’s still work ahead as the wiring will get more complicated as well as requiring a revamp of the electronics control system.

Sawppy at PCC Maker Festival

The city of Pasadena is fortunate to have an organization like Innovate Pasadena to build a community of companies and organizations around Pasadena. The city is large enough that people don’t always know what’s literally down the block. The flagship event is open to the public, to try to get everyone involved. This is Connect Week, a week long event in October filled with events that open doors and hopefully form connections.

Sawppy’s participation in Connect Week is the Maker Festival held at Pasadena City College (PCC). Representing one of the many subsets of San Gabriel Valley Technology enthusiasts (SGVTech.) Sawppy’s nominal job for the day is to roam around, get people’s attention, and direct them to the SGVTech table for more information.

Sawppy and JPL OSR at PCC

Sawppy wasn’t the only rover present, though. SGVTech’s neighboring table represents JPL and one of their Open Source Rover was also present. This is the exact same rover present at Sawppy’s first public outing.

I was a little disappointed at how many people suggested the rovers fight each other. These are robots celebrating exploration, science, and knowledge. They are not combat robots. I am not a fan of Battle Bots, Sumo Bots, or derivatives thereof and I wished these combat-oriented robots didn’t have such a high profile in people’s minds.

For the immediate future, the best thing I can do to raise the profile of non-fighting robots is to show off Sawppy to more people. Hopefully seeing that there’s more to hobby robotics than battle bots will open people’s minds about it.

Limiting Range of Motion for Sawppy Suspension Bogie

Sawppy’s appearance at LA Maker Faire was also the first public trial of the latest feature: a way to limit the range of motion on Sawppy’s suspension bogie assemblies. They were previously joints that were allowed to spin freely. I had known that the bogies shouldn’t actually turn too far, because that would break the wires running out to the wheels. But I didn’t think it would be a problem as long as Sawppy is rolling on the ground.

It turns out I was wrong. When Sawppy explores extreme terrain, it is possible for the bogie to tilt a little too far and gravity works the rest of the way and sprain a Sawppy ankle. I’m sure the actual rovers had a clever mechanism inside their bogie joint to limit their range of motion, but the details of their implementation aren’t apparent from pictures.

Ideally I would redesign both parts of the bogie joint in a way to limit their range of motion, but I didn’t want to reprint all the parts and recut a shaft just yet. For the first draft of this angle limiter, I changed the smaller part to add a nub that restricts the range of motion.

I originally wanted this nub to live underneath out of sight, but due to the angle of the suspension bogie, it turns out there’s no place for such a nub underneath if I wanted to preserve the desired range of motion. So the nub lived above as a very visible difference between it and the rovers that inspired Sawppy.

The angle limiter did function properly during Downtown LA Maker Faire, but I’m not satisfied with its appearance. The part is available directly from Sawppy’s Onshape CAD file, but I think there will be a few more iterations before I push it over to Sawppy Github.

Sawppy at DTLA Maker Faire 2019

Sawppy returned to the downtown Los Angeles Mini Maker Faire for 2019 as a roaming exhibit. This is a change from last year where Sawppy was part of a rover themed booth with other JPL Open Source Rovers. Sadly this year we were missing representation from the JPL Open Source Rover project, none of the three rovers from last year were present this year.

Los Angeles Maker Faire has grown even more this year and spilled into the street, specifically 5th Street adjacent to the library which was shut down for the event to make room for an additional row of exhibits. Many of the larger booths were out here, including a robot combat arena and a few car projects like the Eggscape Eggsperience.

There was forecast for rain, which dampened things literally and otherwise. Fortunately Sawppy is prepared for rain with a rain coat developed for Maker Faire San Mateo earlier in the year, so the light rain was not a problem.

I have fun showing Sawppy to interested attendees, but it is also an opportunity to chat with other like-minded exhibitors. I started trying to strike up conversation with people as soon as I got in line to check in as a maker. It turns out I was behind a member of the Air Quality Management District’s Air Quality Sensor Performance Evaluation Center. They were here at Maker Faire to tell people about the availability of low-cost air quality sensors. Both for AQMD’s own purposes and as something that could be fun for makers to tinker with. They brought a few sensors for show and I asked if Sawppy could act as a mobile air quality sensor for a day… and they said yes!

Even though no JPL OSR builds were present, Sawppy was not the only rover there but most of the others were static 3D-printed models. Probably from here. The one I found actually interesting is a motorized version that was done as an example application of the 3DoT board by Humans for Robots.

It was a fun day of adventure for Sawppy, topped off with a shout-out from Make!

Sawppy Attends MatterHackers Modern Creators Night

MatterHackers is a local supplier for 3D printing. They also carry other products catering to the same hobbyist-grade audience for small scale fabrication, such as laser cutters and CNC engravers. I’ve bought much of my supplies — including the PETG filament used to print the current iteration of Sawppy — from MatterHackers.

I’ve met some of the people of MatterHackers at Yuri’s Night, and been extended an invitation to visit their headquarters where there’s a showroom area. But I have yet to take them up on that invitations because, while MatterHackers is within driving distance, it is a nontrivial drive accounting for LA traffic. Going to that area is basically a day trip, and it kept not happening.

But when Sawppy was invited to be at their Modern Creators Night event, that was enough motivation for me to pack up and take that trip. At the event, I learned it is a scaled-up version of an occasional meetup MatterHackers used to hold at their main office, but there was no longer enough space there. Their business has grown, as has the size of the crowds. Hence – a new event at a venue with a new format.

Sawppy arrived and started roaming the exhibit area as rovers tend to do. But when it came time for the speakers to present, Sawppy was presented with a table for static exhibit. I made some signage I could tape to the table, to explain Sawppy when I’m not present to tell the story.

Sawppy on small MatterHackers display table

There were a lot of 3D prints on exhibit by other makers, and one of them decided to loan their little printed model of Curiosity to keep Sawppy company during speaker presentations. I was happily surprised when I saw this little guy, and didn’t meet its owner until later. I regret to say I’ve already forgotten her name, but her generous and appropriate loan is very much appreciated!

Sawppys little friend

Curiosity Rover 3D Resources

Prompted by a question on the JPL Open Source Rover web forum, I compiled all the 3D resources I had collected on Mars rover Curiosity. This reference data helped Sawppy match Curiosity’s overall proportions and suspension geometry, which was my goal of making a mechanically faithful motorized model. I stopped there, but others rover builders like Laura McKeegan are working to improve accuracy in appearance so I thought I’d share these resources to help such efforts.

3D web sites

My starting point was JPL’s official open source rover web site whose opening animation has a 3D model of Curiosity cruising on a simulated Mars surface. I tried to extract that 3D mesh without success.

On a similar front, we could see a 3D model of Curiosity in the “Experience Curiosity” web site. It’s possible this is using the exact same data set as the OSR, but again I’m not enough of a web developer to pull out the 3D data.

Finally we have a 3D model visible on Curiosity’s mission site. Again it may or may not be the exact same one used in above two sites, but the difference here is that we have a “Download” button. Clicking that button results in a file named Curiosity_static.glb. My laptop running Windows 10 has a 3D Viewer app installed by default, which was able to view this file. I don’t know what viewer software would be required for other platforms.

3D printing

A web search for “Curiosity 3D Model” and similar keywords would repeatedly lead me to a 3D-printable static model. Unfortunately, for my purposes this model is not useful. The geometry of this model were modified to be friendly to 3D printing and is not a faithful representation of Curiosity.

3D animation

However, on the same NASA 3D website, there are two Curiosity models for the free open source 3D animation program Blender. As far as I can tell, these two models have the same 3D data but with different textures. “Clean” is factory fresh Curiosity, and “Dirty” represents Curiosity after cruising on Mars for a while.

The advantage of these files is that suspension parts are separate elements that can be animated to show suspension articulation. I believe these files formed the basis for Gazebo simulation described in this forum thread. It also means we can split parts apart for a closer look. However, this file only has enough detail for animated graphics, it does not have enough detail for CNC machining: much of the surface detail are represented by bitmap textures instead of 3D mesh data.

While there is not enough detail for building a high fidelity model, these files were the best resource I had to measure component sizes and their relative layouts. I was able to bring them up in Blender, switch to orthographic projection view, and get images of Curiosity free of perspective distortion. In case that’s useful to anyone, and you don’t want to install & run Blender just to obtain those images, here they are:

 

(Cross-posted to Hackaday.io)

Sawppy Cleanup After Maker Faire Bay Area 2019

Sawppy had a successful appearance at Maker Faire Bay Area 2019, where the two major novelties were an impromptu raincoat and an emergency steering servo replacement. Once Sawppy was home, though, there were a few cleanup and maintenance items before Sawppy is ready for the next event.

First of all, Sawppy’s wheels are filthy after running around San Mateo Event Center over the course of Maker Faire. There was mud, there was dirt, spilled coffee, dropped popsicles, and rain making all of those problems both better (washing off larger chunks) and worse (spread a thin layer across entire circumference.) Like what happened after Downtown LA Mini Maker Faire, Sawppy needed to kick off all six shoes and give them a nice long soak in chlorine-enhanced water. An retired toothbrush was used to scrub each wheel of dirt particles.  But despite the brushing and the chlorine, Sawppy’s wheels get a little dirtier with every public event. I’m not terribly about this cosmetic aspect, as long as the physical mechanical capabilities are not degraded by worn grousers on the wheels.

Secondly, we have a mechanical issue to investigate. The left rear wheel is now freewheeling instead of helping to propel the rover. This was discovered late Maker Faire Sunday. At that point Sawppy still had to attend Oshpark’s Bring-a-Hack at BJ’s Restaurants, but Sawppy would spend most of that event standing up on a table. So I decided to postpone dealing with that issue until later… now is later! This turned out to be the servo horn screw backing out, allowing the servo horn to slide off that servo’s output shaft. There seems to be some minor damage from chewed up teeth, but a quick test indicates there’s enough remaining to transmit power so Sawppy should be fine.

And finally, we found another consequence of a rainy Maker Faire: Sawppy’s steel drive shafts have started to rust. This seems to have made wheel removal much more difficult so I should investigate rust removal and prevention before reassembling everything.

Sawppy Emergency Field Repair at Maker Faire Bay Area 2019: Steering Servo

Taking Sawppy to Maker Faire Bay Area 2019 was going to be three full days of activity, more intense than anything I’ve taken Sawppy to before. I didn’t think it was realistic to expect a completely trouble free weekend and any breakdowns will be far from my workshop so I tried to anticipate possible failures and packed accordingly.

Despite my worries, the first two days were uneventful. There was a minor recurring problem with set screws on shafts coming loose despite Loctite that had been applied to the threads. I had packed the appropriate hex wrench but neglected to pack Loctite. So I could tighten set screws back down, but lacking Loctite I had to do it repeatedly. Other than that, Friday was completely trouble-free, and Saturday rain required deployment of Sawppy’s raincoat. But Sawppy got tired by Sunday morning. Driving towards Dean Segovis’ talk, I noticed Sawppy’s right front corner steering angle was wrong. At first I thought it was just the set screw again but soon I realized the problem was actually that the servo would turn right but not left.

With the right-front wheel scraping along the floor at the wrong angle, I drove Sawppy to a clearing where I could begin diagnosis. (And sent call for help to Emily.) The first diagnostic step was pushing against the steering servo to see how it pushes back. During normal operation, it would fight any movement off of its commanded position. With the steering behavior I witnessed, I guessed it’ll only fight in one direction but not another. It didn’t fight in either direction, as if power was off. Turns out power was off: the fuse has blown.

I replaced the fuse, which immediately blew again. Indicating we have a short circuit in the system. At this point Emily arrived on scene and we started methodically isolating the source of the short. We unplugged all devices the drew power: router, Pi, and all servos. We inserted third fuse, powered on, and started testing.

Sawppy dead servo 29

We connected components one by one, saving the suspected right-front servo for last. Everything was fine until that suspected servo was connected, confirming that servo has failed short. Fortunately, a replacement servo is among the field repair items I had packed with me, so servo replacement commenced. When the servo was removed I noticed the steering coupler had cracked so that had to be replaced as well.

Using a spare BusLinker board and the Dell Inspiron 11 in my backpack, I assigned the serial bus ID of my replacement servo to 29 to match the failed front right steering servo. Then I pulled out a servo shaft coupler from the field repair kit and installed that on my replacement servo. We performed a simple power-on test to verify the servo worked, plugged everything else back in, and Sawppy was back up and running.

Let’s Learn To Love Imperfect Robots Just The Way They Are

A few months ago, as part of preparing to present Sawppy to the Robotics Society of Southern California, I described a few of the challenges involved in putting ROS on my Sawppy rover. That was just the tip of the iceberg and I’ve been thinking and researching in this problem area on-and-off over the past few months.

Today I see two divergent paths ahead for a ROS-powered rover.

I can take the traditional route, where I work to upgrade Sawppy components to meet expectations from existing ROS libraries. It means spending a lot of money on hardware upgrades:

  • Wheel motors that can deliver good odometry data.
  • Laser distance scanners faster and more capable than one salvaged from a Neato vacuum.
  • Depth camera with better capabilities than a first generation Kinect
  • etc…

This conforms to a lot of what I see in robotics hardware evolution: more accuracy, more precision, an endless pursuit of perfection. I can’t deny the appeal of having better hardware, but it comes at a steeply rising cost. As anyone dealing with precision machinery or machining knows, physical accuracy costs money: how far can you afford to go? My budget is quite limited.

I find more appeal in pursuing the nonconformist route: instead of spending ever more money on precision hardware, make the software smarter to deal with imperfect mechanicals. Computing power today is astonishingly cheap compared to what they cost only a few years ago. We can add more software smarts for far less money than buying better hardware, making upgrades far more affordable. It is also less wasteful: retired software are just bits, while retired hardware gather dust sitting there reminding us of past spending.

And we know there’s nothing fundamentally wrong with looking for a smarter approach, because we have real world examples in our everyday life. Autonomous vehicle research brag about sub-centimeter accuracy in their 3D LIDAR… but I can drive around my neighborhood without knowing the number of centimeters from one curb to another. A lot of ROS navigation is built on an occupancy grid data structure, but again I don’t need a centimeter-aligned grid of my home in order to make my way to a snack in the kitchen. We might not yet understand how it could be done with a robot, but we know the tasks are possible without the precision and accuracy demanded by certain factions of robotics research.

This is the path less traveled by, and trying to make less capable hardware function using smarter software would definitely have their moments of frustration. However, the less beaten path is always a good place to go looking for something interesting and different. I’m optimistic there will be rewarding moments to balance out those moments of frustration. Let’s learn to love imperfect robots just the way they are, and give them the intelligence to work with what they have.

Mars 2020 Rover Will Carry Sawppy’s Name

Modern advances in nonvolatile memory storage can now pack a huge amount of data in a very little space and volume. Everyday consumers can now buy a microSD card representing this advance. One of the ways NASA has taken advantage of this is offering a program where people can submit their names to be carried onboard spacecraft in the form of digital data stored on a tiny flash memory chip.

Spaceflight is still very expensive, with every gram of mass and cubic centimeter of volume carefully planned and allocated. But with flash memory chips so small and light, NASA has decided it offers enough returns on publicity to be worth carrying onboard. Such programs award social media exposure and free coverage like this very blog post!

NASA JPL’s Mars 2020 program, the most visible component of which is a not-yet-named rover successor to Curiosity, will be a participant. There will be a small flash memory chip on board with names of people who cares to submit their name via the NASA web site set up for the purpose.

I don’t care very much about having my own name on board Mars 2020, but I loved the thought of having “Sawppy Rover” as one of the names on board that actual rover heading to Mars. I’ve submitted Sawppy’s name so hopefully a few bits of digital data representing Sawppy will accompany Mars 2020 to and travel across Martial terrain.