[ROS Q&A] 095 – Controlling right and left wheels using ROS

In this video I will answering the following question asked in ROS Answers: https://answers.ros.org/question/279465/controling-right-and-left-wheels-using-ros/

[ROS Q&A] 094 – Visualising the real time trajectory path using markers

In this video we show you how to see your own Marker in RViz. The code used is detailed in the question (https://answers.ros.org/question/279558/visualising-the-real-time-trajectory-path-using-markers/)

Q: How to see my Marker in RViz

A: The marker was working. In this case the user just should select the correct “frame_id” and correct “Base Link“

[ROS Q&A] 093 – How to see a ROS Image that is published in a remote computer

On not using ROS for your robotics startup

This post comes as a reply to the post written by Antti Alhonen from Pulurobotics, where he stated his reasons for not using ROS on the robotics products of his company.

Having read the article, I do agree with him that not every robotics product must use ROS. It depends. ROS introduces an overhead in the development process that it may not be worth the trouble depending on the type of robot we are building. For example, very simple robots that can work with a small controller board, like for example the Sphero robot, may not require to use ROS (however, here there is the code that ROSifies a Sphero robot, and here a post about how to develop ROS programs for that robot using that ROSification). So, I completely agree that for those little robots with no (actual) computer onboard,  ROS is not worth the price.

However, mobile base with navigation and sensors to autonomously interact with people… definitely yes!

What is the most optimal in terms of engineering, may not be the most optimal in terms of business.

I would even say more: what is more optimal in terms of personal satisfaction of the engineer that is creating the robot, may not be the most optimal in terms of business. It think that the key term here is personal satisfaction.

Engineers, we always want to redo everything, because we don’t like to have to read and understand what the previous engineer has done:

The previous programmer’s work is very bad (even if the program has been doing its job for x years already). I can do it better from scratch than reading and understanding his  messy code.

This is a typical attitude in us, engineers. We always prefer to do it ourselves (I am guilty of that!), and we feel satisfaction of doing it. Of course, if we had all the time of the world, and infinite resources, then it would be a good decision to build our own and optimized system. However that is never the case. We need to meet deadlines, and worst  than that, we need to maintain our business in the long run. So reusing what has already being done by others is key if we are in the market… unless we only want to spend the investor’s money and have fun (but it that case, we are not building a business, we are doing a hobby).

Just as an anecdote, while I was working at Pal Robotics building humanoid robots, the electronics chief wanted us to develop from scratch the sensors that the robot was going to use. Imagine the overhead for a company that doesn’t know how to build a camera, now having to design a camera, while anybody else can go to the ROS Components store and buy one that is plug and play in the robot in a matter of minutes. Yes, the bought camera has a given shape that cannot be changed, and one has to deal with that for the sake of simplicity and speed. Furthermore, at the end of the day, the camera company knows a lot better than us how to create a camera, and it is very unlikely that we are going to build something better.

Two big (wrong) claims of the article

There are two big claims in the article that I think are wrong.

The first one

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 team of ten people to achieve in 2-3 years using ROS (based on what we have seen while analyzing the market).

From the page of Pulurobotics, I see that they are developing a mobile platform that moves around, using SLAM to navigate and exploration to autonomously create the maps. On what relates to the software part, those things can be done by a single person in a matter of hours by using ROS.

•  SLAM. This is done off-the-shelf with ROS. Right now. 30 minutes to set a navigation system up in a ROS running robot (I have multiplied by ten the amount of time that I really think is needed,  for a safety margin). Check this wiki page for information about the ROS navigation stack. Check this online course to learn how to use the navigation stack.
• Autonomous mapping (exploration). Also done. Check this code for multiple robots doing autonomous mapping with ROS (can be used from 1 robot to many), and this other video about how to set it up in 5 minutes.
• Need to communicate with the tablet on top? Use ROS Bridge and have your app sending commands to the base in a matter of hours.

So I don’t agree at all with the first claim.

Second wrong claim

ROS would actually solve around 10% of our problems. The rest 90% would get twice as tedious, at least.

ROS can solve off-the-shelf 90% of your software problems. I’m pretty sure that many of the things their robot needs, is already done inside ROS, and can be reused in that project. Also ROS has the tools for debugging and maintaining the code. It also has have the system to simulate the robot and test prior to deployment. I mean… that is huge!

Again, I don’t agree.

I do agree on the 90% tedious claim. It is tedious to have to learn and adapt to a framework that one doesn’t master, and make our system compatible with it, that is, to ROSify the robot  (in the same way as building Unit Tests for  code checking is a pain). But the question here should be, what is the best for my business?

Main problem of the post: not having a software background

From an analysis of Pulurobotics’s website, I think that the author and his team are mostly mechanical and electronics engineers and lack a strong software background.

While I was at Pal Robotics, mechanics engineers had a said at our lab for things that were very simple:

That is as easy as writing the software.

Writing software, as perceived from mechanics and electronics, is just a simple thing that can be done in a matter of minutes, and that we, software developers, are over-complicating (for some obscure reason).

Software is the limiting factor in robots

Let me clarify for the sake of truth: the main barrier in robotics preventing us from having robots everywhere is at the level of software, not at the level of electronics, not at the level of mechanics. Of course, electronics and mechanics can be improved a lot, but they are not limiting today the fact that we have a robot that drives our cars. What is preventing those robots to exist is the software. This point is beautifully explained by Gajamohan Mohanarajah, CEO of Rapyuta Robotics in his TEDx presentation, where he shows how a PR2 robot can clean a full room when remote controlled by a human. The mechanics to do that is already on place and working. The electronics too. The only point missing is the software, and that is why some person must remote control it.

It is software where the final barrier is. And by saying that, I’m not trying to start a kind of religious war. I’m just stating a fact, like the video of Gajamohan beautifully expresses.

However, thinking of software as something simple is not their fault. Mechanics and electronics engineers suffer the problem of not being able to iterate fast (building a new version of a mechanical piece or electronic board can take days for them, but for us it just takes some seconds to change the code and relaunch). So, they cannot understand how is it that it takes us so long to do the program right, when development can be so fast. Also, anybody can do a program that does something. So, the perception that software is easy task.

Reasons to adopt ROS in a startup

The reasons why I believe that ROS is key for a robotics startup:

• Creating the MVP. I may accept that you do not use ROS for your product. But, what about building the MVP? (Minimum Viable Product). Again, are we talking about building a business or a hobby? If it is a business, you cannot build your product from scratch, develop all the fancy electronic boards and mechanics, and then hope to see if there is a market. You first create an MVP and test it with the public. No way there is a faster way to create such an MVP of a service robotics product than with ROS.
• Time to market and maintenance. You cannot build a complex robotics product faster if you need to develop all the software. Is going to take ages to have the software right. Unless you contract a team of software developers, good software developers, I mean, expensive ones. And remember that the team will have to build, not only the robot software, but the  tools to debug and find errors (all that provided off-the-shelf by ROS).
• Community ready to use your product. The number of people that knows ROS is increasing year after year. You need your product to be adopted fast. Also, you need that people from the world start developing for your robot. Finally there is the access to the community. By not making a ROS product, your product is completly out of the ROS circuit, so you cannot have access to all the code that is writen by third parties. You will have to start creating your own community. That is an overhead.
• Recruitment. It’s easier and faster to recruit for people with ROS knowledge that will be up to speed at your company faster.

As you can see, all the reasons I argue are business related. None are about the engineers are experiencing while developing.

While you are doing your first SLAM algorithm that works, your competitors are already making the robot understand vocal commands + SLAM + manipulation by using ROS. And the things just get worst as the project evolves, and you need to maintain the software.

Conclusion

In my opinion, I think that the article is more about doing the things one likes to do than doing an effective work. Being efficient but not effective.  I think that for a startup, the opposite must be the aim (being effective, not efficient). Also the article is stating a lack of knowledge of ROS and how it can speed  up the product to market time and simplify in the future the maintenance of the product.

I do understand that ROS has a stepped curve of learning, specially if you are not a software developer. That is why at our company, The Construct, we have built an online academy for fast learning of ROS (Robot Ignite Academy). I heavily recommend everybody to give it a try for free here and see how easy it could be to learn ROS with a good method (additionally, in case you like it, you can use the discount coupon MVP01201 for a 10% discount).

I can only say that Pulurobotic’s competitors are do using ROS. Here of some of the competitors that use ROS:

1. Robotnik Summit XL
2. Milvus Robotics MRP2
3. Neobotix MPO-700
4. Husarion ROSbot
5. Pal Robotics PMB-2
6. ClearPath Ridgeback

Judge by yourself.

Definitions:

• Efficient: doing tasks very fast
• Effective: doing the tasks that matter

[ROS Q&A] 092 – Incorrect opening a urdf file in Gazebo

How to fix an issue in which the robot model joints break and collapse: https://answers.ros.org/question/279033/incorrect-opening-a-urdf-file-in-gazebo/?answer=279141#post-id-279141

Q:Incorrect opening a urdf file in Gazebo
A: You have to recalculate the inertias because they are totally wrong.

[ROS Q&A] 091 – Python variable scope problem