Notes on Exploring Curio ROS: ros_control

When learning something new, I always find it useful to find a part that I could use as a foundation. Something I can use to build my new information on top of. I had trouble finding such a foundation for ROS as it was such a big system. So it was a great gift to have the chance to look at Rhys Mainwaring’s ROS stack for Curio rover, a sibling of my Sawppy rover. This meant the rover I designed and built was my foundation for learning Curio’s ROS software stack.

Such a foundation was less critical when I had explored Curio’s interaction between Arduino Mega and Raspberry Pi. But it was very useful when I explored how command messages were sent around inside the system. This was built using ros_control, a set of ROS packages that help abstract the concepts of robot motor control from the actual details of motor controller commands.

The promise here is allowing a robot builder to swap around different motor controllers without changing the logic about how a robot would use those motors. Conveniently, Sawppy has both of the basic categories: “Joints” specify a position, and that fits Sawppy’s four corner steering servos. Whereas “Transmission’ specify rotational motion like Sawppy’s six wheel motors.

The idea of abstracting motor control from implementation is common, I even had a primitive form of it inside SGVHAK_Rover software allowing us to hack a servo into a RoboClaw placeholder, and later adapted to Sawppy’s LX-16A serial bus servos. The power of such abstraction comes when it becomes open and flexible enough for software modules implementing either side of the abstraction to be reusable beyond its original author’s use. That certainly was not going to happen with a homebrew pack of servo software, but a convention in ROS is a different story.

Which is why I was puzzled to learn ros_control does not appear to be in the works for ROS 2. It is absent from the index, and I found only a discussion thread with no commitment and this page with a dead link. I thought ros_control would be a fundamental part of the platform, but it is not. Its absence tells me there’s an important gap between my expectation and ROS community’s actual priorities, but I don’t know what it is just yet. I’ll need to find its successor in the ROS2 ecosystem before I understand why ros_control is being left behind.

Notes on Exploring Curio ROS: Arduino Mega

I was very excited when I learned Rhys Mainwaring created ROS software for Curio rover, a sibling of my Sawppy rover. An autonomous Sawppy on ROS has always been the long-term goal but I have yet to invest the time necessary to climb the learning curve. Rhys has far more ROS experience, and I appreciated the opportunity to learn from looking over the Curio Github repository. Here are some of my notes. written with the imperfect accuracy and completeness of a ROS beginner learning as I go.

The most novel part of Curio is obtaining odometry data from LX-16A’s position sensor with the use of a filter that recognizes when we’re in the dead zone of that position sensor and rejects bad data. I believe Rhys has ambition to extrapolate position data while within the dead zone but I didn’t find the code to make it happen. Either I missed it or that is still yet to come.

I love the goal of odometry calculation without requiring additional hardware, but Rhys ran into problems with bandwidth and a little extra hardware was brought in to help as (hopefully?) a short term workaround. While Sawppy didn’t need to communicate with the servos very frequently, Curio needed to also poll servo positions far more frequently for the odometry filter. Rhys found that the LewanSoul BusLinker board’s serial to USB bridge could not sustain the data rate necessary for the filter to obtain good data.

As a workaround, Curio makes use of an Arduino Mega 2560 to communicate with BusLinker via its 5V UART TX/RX pins, and then translating that to USB serial for the Raspberry Pi. The Arduino Mega is necessary for this role because it has multiple hardware UART necessary to communicate with both BusLinker and Raspberry Pi at high speed. I only have Arduino Nano on hand, with a single UART, and thus unsuitable for the purpose.

Curio’s Arduino Mega also has a second job: that of interpreting PWM commands from a remote control receiver, relaying user commands from a remote control transmitter. This is an alternative to my HTML-based control scheme over WiFi.

Curio’s Arduino communicates with its Pi over USB serial, using the rosserial_arduino library. Rhys has set up Curio’s Arduino firmware code such that its two jobs can easily be separated. If a rover builder only wants one or the other function, it should be as easy as changing the values of ENABLE_ARDUINO_LX16A_DRIVER  or ENABLE_RADIO_CONTROL_DECODER to trigger the right #ifdef to make it happen.

Inspiration From Droids of Star Wars

Today is the fourth day of the month of May, which has grown into “Star Wars day” due to “May the Fourth” sounding like that film’s popular parting line “may the Force be with you.” A quick search confirmed I’ve never explicitly said anything about Star Wars on this blog and that should be corrected.

By the time I saw Star Wars, I had already been exposed to popular science fiction concepts like space travel, interstellar commerce, and gigantic super-weapons. And the idea of a cult that promises to make their followers more special than regular people… we certainly didn’t need science fiction for that. So none of those aspects of Star Wars were especially notable. What left a lasting impression was R2-D2.

R2-D2 had its own expression of duty and loyalty. Companion to humans, and a Swiss Army knife on wheels. A character that managed to convey personality without words or a face. R2-D2 was the most novel and compelling character for me in the film. I wouldn’t go far as to say R2-D2 changed the path of my life, but there has definitely been an influence. More than once I’ve thought of “does this help me get closer to building my own R2” when deciding what to study or where to focus.

I was happy when I discovered there’s an entire community of people who also loved the astromech droid and banded together to build their own. But that turned to disappointment when I realized the dominant approach in that community was focused on the physical form. Almost all of these were remote-controlled robots under strict control of a nearby human puppeteer, and little effort was put into actually building a capable and autonomous loyal teammate.

I can’t criticize overly much, as my own robots have yet to gain any sort of autonomy, but that is still the ultimate long-term goal. I love the characters of R2-D2 and the follow-on BB-8 introduced in the newest trilogy. Not in their literal shape, but in the positive role they imagined for our lives. This distinction is sometimes confusing to others… but it’s crystal clear to me.

Oh, I thought you loved Star Wars.

Star Wars is fine, but what I actually love are the droids.

I still hope the idea becomes reality in my lifetime.

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 remember 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 Curio

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.