Some Thoughts on Robotics Startups

This is not investment advice.
This probably shouldn’t be construed as advice of any kind.

Robotics Startups of the Past and Present

Over the past year or two, I’ve had a number of conversations that were basically “why is it so much harder to get funding for robotics stuff these days?”. While you could blame macroeconomics, lack of LP liquidity, and higher interest rates, I think this actually largely comes down to the fact that there haven’t been all that many really big exits in robotics. Robotics founders tend to be very good at building cool tech solutions, but not so good at actually selling and monetizing that technology.

When Kiva Systems sold to Amazon in 2012 for $775M, there weren’t all that many robotics companies out there - so it looked like maybe this was a space that would generate great returns. Now, a little over 10 years later, there have been a handful of exits in the several-hundred-million-USD range (Universal Robots, 6Rivers, MIR, Fetch Robotics, Clearpath Robotics / Otto), but most of those raised significantly more capital than Kiva Systems did and all of them exited for a lower price than Kiva. None of them exited at the same kind of crazy valuation that Google bought Nest for in 2014 ($3.2B - this was another “hardware” exit that drove interest in robotics around that time).

Universal Robots and Mobile Industrial Robots (MIR) are setup more like traditional robot manufacturers - they build robots, sell them at relatively low margins, and use an extensive network of integrators who actually install and program the robots. Notably, both companies come out of the EU - I feel that most US-based investors who do seed/A rounds would not fund this sort of company today.

What those US-based investors do fund looks a bit different. These companies are largely founded by robotics experts. They are vertically integrated, often manufacturing their own robots in-house, building their own mapping, localization, navigation, and cloud-based fleet management, and often setting up their own direct sales channels. Many of those direct sales channels focus on “recurring revenue” by offering robots as a service. There are numerous examples.

One outlier to this model though would be Locus Robotics. They weren’t founded by robotics experts - they were founded by domain experts in third party logistics (3PL). These domain experts were also a built-in customer - as an early customer of Kiva Systems, they had a real need for a new robotics solution after the Kiva acquisition And hey, guess what, Locus is doing pretty well.

Robotics is not SAAS

What surprises me is there are still investment firms trying this same playbook today. They go out and fund a robotics company founded entirely by roboticsists (and for some reason, many seem to think there are bonus points if every one of the founders is a Robotics PhD and has never held a job outside of academia).

Some of these firms claim that RaaS is the new SaaS: spoiler alert - it’s probably not! Robotics is capital intensive. Especially if you are buying all these robots, keeping them on the books, and then renting them out with a 1-2 year payback window. Even worse: robots age a lot worse than servers.

The really tricky thing about “robotics startups” is that the robot is JUST ONE PART of the business / product. It’s really just the starting point - and you will eventually end up expending far more effort on the rest of the product: the software you need for deployment and monitoring, the sales organization, the integration teams.

Finally, while many folks will tell you that “hardware is hard” - the bigger problem is that hardware is SLOW. Supply chains have improved from the days of the pandemic, but they are still slow, inefficient and generally a bit of a hot mess. So when you do suddenly land all those orders - good luck getting the parts you need to actually fulfill the order quickly.

/rant

Robotics Ecosystems

And now we get to something maybe actually useful to somebody. If our current generation of robotic startups are fully vertically integrated and founded solely by robotics people, what does the next generation look like?

Much of the really interesting stuff with computers and the internet started to happen when people who weren’t just computer nerds were able to build companies in the space. I think the same thing could happen for robotics.

These next generation robotics companies will have a founding team with domain experts in whatever problem the robot is solving. These companies probably won’t even be called robotics companies. They’ll be healthcare automation startups, or 3PL startups, etc.

They probably won’t be fully vertically integrated, instead choosing to use more off the shelf hardware and software components.

We already see some of this happening today - in the early days of the RoboBusiness conference, all sorts of “robot” companies exhibited - today, those robot companies put much more emphasis in the tradeshows for their industry - show likes ProMat or Modex for warehouse logistics providers. The majority of exhibitors at robotics conferences are now selling (largely hardware) components to robot companies.

With an ecosystem of more focused next-generation robotics companies, these startups won’t have to build everything in-house. Companies like InOrbit, Formant and Foxglove exist today and offer a slice of tools needed to build a robotics solution. You can buy robots from UR and MIR. The ROS 2 variant of navigation, Nav2, and arm planning (MoveIt2) are already being used in commercial products with far less customization than was needed in ROS 1 - and their respective supporting companies (Open Navigation LLC and PickNik) exist to help next-generation robotics companies leverage these open source projects.

The Actionable Stuff

Numerous people have asked for startup advice over the years - I have often, wrongly, focused on very narrow things (don’t go cheap on lawyers, etc).

I’m not sure I’ll ever do another robotics company, but here is what my dream founder team would look like for a future robotics startup:

• CEO - A domain expert in whatever industry you are selling into. Significant product experience. Should be able to sell - the CEO’s industry connections will basically take the place of hiring a sales team initially.
• CTO - Robotics expert, with product experience. In order to properly lead the (hopefully relatively small) engineering organization, and integration of Off-The-Shelf (OTS) components and vendors, the CTO will need a solid grasp of hardware, web/enterprise software, and any other product specific technologies.

Put that team together and then find a real product need - the simpler the better. Robotics people love to over-complicate things. Do you really need a mobile base? Do you really need an arm? Or is there some simpler automation solution that you should be tackling?

ROS 2 in Parallels VM on MacOSX

While I sported a Linux laptop throughout grad school, my Willow Garage days, and my early startup years, I’ve been using a Macbook Pro as my daily driver for about a decade now.

That equates to a lot of “ROS on Mac” pain.

Things were supposed to get easier with ROS 2.

Back in 2020, I installed ROS 2 natively on my last Intel-based Macbook. You can read all about the fun of compiling from source.

Then Apple moved to their new M1 architecture, ROS downgraded OSX to Tier 3 support, and I got older and maybe a bit more grumpy. For all of these reasons, I decided not to do a native installation for ROS 2 Humble. I tried out a few approaches as documented here, but ended up settling on using a Parallels VM.

Yes, Parallels costs cash money. But, how do you value your time?

Parallels Installation

My original post had a quick run down of my installation, but here is a recap:

• M1/2/3 architecture is ARM64 - which is Tier 1 supported!
• Ubuntu has an ARM64 installer - but only for server, so you have to do a few extra steps - but there is a detailed description of the workflow on askubuntu.com

Issue: RVIZ2

rviz2 runs well inside the Parallels VM, especially if you avoid using “points” as the display type for laser scan and point cloud messages. There seems to be a bug there that causes frequent crashes - but only for that display type. I’ve had great success with Flat Squares as the rendering type. I’ve also had no issue visualizing points in a visualization_msgs/Marker.

Issue: Bridged Networks

If you just want to develop locally within your VM, then you can keep right on using the “Shared Network” profile and skip over this issue.

However, if you want to connect to a robot and actually stream data from ROS 2, you will need to change from “Shared Network” to “Bridged Network”. This sounds easy, however, it appears there are numerous issues with Parallels creating bridged networks (their support forum was a wasteland of these issues, all unanswered). I could not get the default network to even come up with a bridged configuration.

The workaround appears to be to create a second network adapter, and make that one bridged. Since the primary network is still shared and comes up as expected, your Ubuntu VM will boot, and then you can configure the bridged network within the VM. I found that using a fixed IP was the most reliable approach:

• Shut down the VM
• In the Parallels Configuration screen, add an additional network adapter, and select “Bridged Network”, and the appropriate adapter on the Mac.
• Boot the VM
• I configured the network adapter with a fixed IP and then started up:

   sudo ip addr add 192.168.0.150/24 dev enp0s6
   sudo ip link set dev enp0s6 up
  

Issue: Disk Size

About a year later, I started to run out of disk space. I had created the VM with a 64GB drive in the Parallels configuration, but inside the VM it only reported a 32GB drive. Apparently, this is a side effect of using the server installation of Ubuntu - the drive won’t automatically be fully sized. The good news here is that we don’t need to use tools like gparted as we are only adjusting the logical partition. I got my other 30GB with:

sudo lvresize —resizes —size +30G ubuntu-vg/ubuntu-lv

Summary

This is a pretty short post - because things are mostly working. I’ve been using this setup over the past few weeks to connect RVIZ to my RoboMagellan robot while it is navigating around outdoors. I’ll have some RoboMagellan-specific posts coming up soon.

Navigation2 for Small Robots

Earlier this year I built a small robot for the RoboGames tablebot competition. You can read about that robot in my previous post. I’ve now decided to update that robot for Robogames 2024, and also have the robot tackle the fire fighting competition.

Hardware Upgrades

I competed in this fire fighting competition about a decade ago, using a robot with just an 8-bit AVR microcontroller for a brain and a bunch of dedicated sensors. This time around, I’m going to leverage ROS 2, Navigation2, and a thermal camera.

To accomplish this, I’m using a low-power Celeron-based computer. It’s smaller and lower power than any of the NUC computers I’ve used before and runs right off 12v. I added a second battery to support the computer.

I 3D-printed an entirely new chassis for the robot, in fire engine red. The neck assembly contain the LD-06 lidar, and will soon have the thermal camera and a fan to extinguish the candle:

I also built a mock up of the arena. I didn’t quite have an 8’x8’ area for the arena, so I scaled everything to 7’x7’. In the real competition the hallways will be 2” wider, so I expect that navigation will work better in the real thing.

Step 1: Build a Map

The first step once the robot was mostly assembled was to build a map. The standard approach in ROS 2 is to use slam_toolbox.

Normally, this works pretty much out of the box. But the default parameters are all tuned for full size buildings, and my entire arena is about the same width as a typical hallway.

First change was to reduce the resolution of the map. I initially tried to map with a 1 centimeter grid, however this seemed to cause issues because there is a decent amount of noise in the low cost laser scanner I am using. A grid scale of 2 centimeters caused the scan matcher to perform significantly better without overly risking the map narrowing the hallways and doorways.

With the scan matcher now working, I began to map - but the map consistently exploded about half way through. I pulled up the visualization of the pose graph in RVIZ, and realized that we were getting false loop closures everywhere. The default loop closure search size is 2.0 meters - that’s as big as the whole arena. Turning this way down allowed the map to complete mostly intact.

Step 2: Localization

With a map in hand, attention is turned towards localization. There are a number of parameters to tune here, and so visualization is a needed tool. Nav2 uses a new, custom message for publishing the particle filter poses - so it is important to install the nav2_rviz_plugins package.

With the particle filter poses visualized, I set about making a few changes:

• Since the map is so small, and the robot moves so slowly compared to a full size robot, I reduced the update_min_d parameter so that localization will be updated frequently enough.
• I drastically reduced the alpha parameters for the motion model. Since the robot is quite small, the errors are also quite small. To get good values for the alpha parameters, I basically tweak the settings until the particle cloud diverges just the right amount - not too much, but not too little either. I’ve frequently seen people tune the parameters to be too tight, leading to a lack of particle diversity, which can cause the cloud to converge to an incorrect value and never get back to the correct pose.
• Since we are using the likelihood model, only two parameters are used for the probabilistic model: z_hit and z_rand. Since the environment won’t change during the competition, and there are pretty much no unknown obstacles, these can be set quite aggressively. z_hit is set to 0.98, and z_rand is 0.02 - this basically encodes that there is a 2% chance of a measurement that is not based on something in the map.

At this point, localization was somewhat working, but not entirely reliable. Starting to dig into the scoring a bit more, I reduced the value of laser_likelihood_max_dist thinking that would make a big difference since the default is 0.2 meters and my hallways are only about 0.35 meters wide. But this had negligible effect. In reviewing the classic blue book (Probabilistic Robotics by Thrun, Burgard and Fox), I noticed that I wasn’t actually changing the correct parameter. sigma_hit was what really needed adjustment since it controls how fast the probability drops off. Dropping this from 0.2 to 0.025 made a huge improvement in localization.

A few random remarks:

• In reviewing the blue book I noticed that pretty much every implementation of AMCL out there (and there are now several) don’t treat unknown space outside of the map the way the book does. Every implementation propagates the Gaussian values in both directions from the wall, rather than only going into the free space that was raytraced during the map building phase. It would seem that in some environments, this change could actually help with localization accuracy.
• In working with such close range data, I started to wonder if maybe there should be some accounting for how long the range measurement is when computing the probabilities. Most of the lasers on the market today specify the error as a percentage of the range measured, and all of them have worse accuracy for longer range measurements.

Step 3: Navigation

The next step is to fire up Navigation2. I setup my config and launch files as a copy of the configuration that I used for the UBR-1 robot navigation and then started adjusting for the application:

• I reduced the costmap size to 0.02 meters to match the map, tightened the goal tolerances, and defined a square-ish footprint for the robot.
• For my local controller, I set the appropriate velocity and acceleration limits and drastically reduced the lookahead distances.

I was not getting the results I wanted at first with the GracefulController, so I tried switching to the new MPPI controller. However, that turned out to not be so easy. The MPPI controller is heavily optimized with vectorization/SIMD instructions - but - I’m on a fairly low power Celeron processor that doesn’t support many of the newer SSE / AVX instructions. I tried to build from source and deactivate these optimizations, but kept running into an illegal instructions and eventually returned to tuning the controller I know.

I will note that the Navigation2 documentation has some great documentation on debugging in complex ROS 2 projects. These notes allowed me to launch the controller server in an xterm window, attached to gdb, and see exactly what illegal instruction I was hitting:

Next Steps

That is pretty much where this project is at right now. I’ve got semi-reliable navigation that isn’t entirely fast yet - but that’s not bad for just a few hours of work. I’m going to continue tuning the navigation while also getting the higher level controls worked out for the robot to complete the fire fighting task.