We don't need to use ROS

We started doing robotics for our own, practical need, in February 2017, with no experience in robotics whatsoever, and hence, no idea how it "should" be done. I was experienced in designing electronics and embedded software, including power electronics, EV traction, and image sensors, but never in the field of robotics.

Naturally, while I was developing our game-changing (mostly price-dropping) integrated electronic design, we looked at the ROS. "Everybody's using it, so it has to be good." But things are not just generally "good" or "bad"; a hammer is an excellent tool for a nail but not for a screw. The fact that others use ROS shows that it solves their problem (or they think it does). But do we believe that it answers ours?

Starting from the scratch is sometimes the right solution.

I tried to write a ROS driver for my HW. If the learning curve would have been easier, things could be different, but nothing came out of it, making us question whether we need this at all.

After analyzing the situation, we wrote down what ROS is, and what our needs are, and found little in common.

ROS is there to integrate the multitude of existing sensor, actuator, etc. hardware, often hard to use and incompatible as is, by converting their datastreams into a message bus, with compatible datatypes between the hardware drivers and calculation units. It's also a set of conversion interfaces to run several external (i.e., not developed for ROS) open source computation algorithms.

ROS also offers tools to assist researchers in testing out things when they go out and buy a new $1000 or $5000 piece of robot hardware. So, ROS is a translator, and ROS is "the common language"; both between the robot parts, and between the robotic designers. All of which sounds great when you state it like this.

Our business is entirely different. We are designing a capable robotic platform as a complete, integrated solution, for several reasons:

1.) Developing all the parts by ourselves in an integrated fashion is the only way to drive the price of robotics down by a factor of at least ten. If we were to build our robots using "robotic components," as almost everybody else seems to be doing, our total Bill-Of-Materials would be at least $5000 (like with everybody else), necessitating at least $15000 market price (which is indeed where the competition starts).

2.) Connecting complex, separate modules (not designed to be compatible with each other) together is an inefficient and weak use of development time; even when it's done using a middleware such as ROS; even if it's the legendary "someone else" doing the drivers and data conversion. 

3.) We are not going to offer a "swap parts, test each new robotic component out" possibility at all, that's not our product, nor our business model. ROS is great at providing a platform for that purpose; we would use it if this were our business. Instead, we are building our own components, integrating them together efficiently at the lowest level - as simply as possible - and trying to find the components that perform the best, so that our customers don't need to do the low-level design work. Then, we provide a complete platform to the community; we hope to give you a jump start in designing real applications on this platform, instead of reinventing the necessary glue between variable blocks all the time. Of course, because it's open source, anyone can still modify the platform if they wish, but it's not a puzzle that requires solving before anything can be done.

The "ROS way" is inefficient

I could be in your T-shirt?

I started implementing our robot a little bit in isolation from the outside world; in hindsight, that was great.

Let me give you an example. When tasked with getting LIDAR (rotating laser scanner) data out for mapping, I intuitively created code that uses almost zero-latency wheel odometry and gyroscope data to process each LIDAR range data point. That is the current robot coordinate estimate, efficiently eliminating all stretching artifacts which would appear if a LIDAR scan was handled as a single stationary "frame" while the robot moves during the acquisition.

For me, this was a no-brainer, but later, looking at how others have implemented this in a ROS environment, I was horrified to see that the issue is typically just ignored entirely. It is understandable because while this problem is straightforward to solve on the integrated low level I was working on (no extra code - just use the newest information since you have all you need in the same CPU already!), it's much more difficult to do when you have a non-realtime system receiving non-realtime data from multiple incompatible hardware devices, plus artificial software barriers in the name of "modularity". Solving this lidar issue in difficult ways is actually something researchers write complete (and complicated) papers about, as I found out later!

For our price segment, expensive computers are also out of the question; we need to run everything on a Raspberry Pi 3. And we want our product to be feature-rich, agile, quick, and energy efficient. Even from the environmental point alone, we cannot afford to convert tens of watts of power into heat by running inefficient code, inside the millions of robots we are going to swarm this planet with.

So while others were putting together $100-$1000 sensor and actuator modules, some through high-latency USB, and processing the data always too late in a complex message passing architecture inside an expensive computer, our solution directly uses the $1 components found inside those $100 modules, all connected to a single microcontroller, running simple low-level real time code with no operating system, and providing the primary "central nerve" system of the robot, using 200mW of power to do that.

The inefficiency is not only in the cost or power consumption. Having looked at projects utilizing ROS, we have identified that programmers are needed to solve the same problems over and over again: how to "glue" the parts together in the ROS system; how to provide marketable user interfaces instead of demo/research applications.

We have developed everything from scratch, and have reached the same level of actual functionality with a team of three in six months than what it usually takes for a group of ten people to achieve in 2-3 years using ROS (based on what we have seen while analyzing the market). A lot of hard work is still ahead, especially in the software side, but it's great when the demos are actually running on prototypes that have actually manufacturable design inside, with all the CAD/CAM available, with BOM cost compatible with our market price goal even in 10-unit batches.

We never aim to just produce a demonstration using demonstration-specific (expensive, non-manufacturable, or otherwise useless) hardware.

ROS is not the problem, but neither the answer

Pulu is Finnish and means pigeon, which is everywhere in urban environment

I like to work by identifying a problem, finding the root cause to it, and then either fix it or completely redo it.

With affordable mobile robotics, the problem is easy to identify: expensive, hard to use, often unreliable components, and lack of programming skills, resources or team coordination to build a complete system, usable in real-world "customer cases."

I don't know if the ROS project was thinking precisely along those lines, but at least they are apparently solving the same problem - the right problem. However, they are not fixing the root cause - I guess many "ROS thinkers" actually seem to like the way it is.

The foundation for robotics today is often a system that is way too complex. ROS sits on the top of the complex, expensive system, adding a lot more complexity to it, and somehow succeeds to manage that puzzle; I'm impressed how well it works, having seen some great demos.

In our opinion, answer to the complexity problem must be to remove the complex parts instead of managing them. But if we remove the parts being the foundation of mobile robotics, we have nothing left. So we have no choice but to redo everything from scratch.

While doing everything from scratch sounds like a daunting task, please remember that's exactly what the premise of ROS was: let's design and implement this massive software thing once so that everyone can reuse it later.

In our case, doing the "massive thing once" is made possible by stubborn simplification. We simplify each problem in its most basic form. If something seems complex, instead of adding to that complexity, we must dig deeper until we are at the lowest level possible to fix the cause of that complexity. We want to get the foundation right.

The foundation is in mechanics and electronics. (Including low-level firmware.)

ROS is middleware. This is also why we don't compete with ROS at all. This is why we are not redoing their work, and why I said that 90% of what we do is not answered by ROS. We think we don't need middleware - our "stack" is just timing-critical low level (embedded) and computational high-level.

We'll be ROS compatible (whatever that means - please tell us!)

Navigating to the future

Finally, what we have found out, is that ROS is a competent system with a large community, and apparently has found its place in many institutions and companies. We encourage everybody to make their own, informed decision. We all have our motives. Never trust any opinion blindly - make technical decisions based on your technical analysis, so that it applies to your business model.

So, naturally, we don't ever want to discourage anyone, and for those fluent in ROS, or getting their inspiration from the "ROS way," we want to help and join the movement.

For this reason, we decided (from day one) to provide a ROS driver for our hardware. On the other hand, we never are very good at trying to fulfill the software needs of others (instead of our own need). We have too little experience in the ROS architecture ourselves, so it's probably a win-win situation if someone in the ROS open source community gets the inspiration to help us - we have already had a few contacts, people apparently want to do that, showing the positive drive in the ROS community.

We are going to publish all the software as open source, without limitations, so I'm 100% sure Pulu products will be a big hit in the ROS community as well, even if we don't use ROS internally right now.