Why don't we use ROS?

keshavchintamani · 2017-11-14T09:08:57.747Z

In my time managing a team that used ROS for a large European research project and my time with ROS at home, I think the hardest part of ROS is the steep curve offered by the dependency and build system - make, cmake, gcc, et al…

I offered a tutorial on ROS once to a couple of Java developers and they stopped speaking to me thinking I’d take them away from their murky maven builds and drown them in make files!

While the existing tutorials makes it easy to setup from apt and get going, the hard part comes when you have to build topics with covariance, time synchronization and all the other good stuff to make your robot work. For example, I remember struggling to ENU transform my IMU for robot_localization and I just couldnt find a location with a good description even on Answers.

Still I’m a big believer in ROS and experimenting with ROS2 where many of QoS limitations are taken out. I think its the only way of prototyping robots today despite the learning curve. Building monolithic applications is so 2008 but a good option still if you want to be like Golem from the Lord of the Rings

basdebruijn · 2017-11-15T08:00:20.565Z

iluetkeb:

Has anybody used machinekit to drive, say, a mobile robot’s wheels, including Odometry and IMU integration?

Not that i’m aware of. This would typically be a setup where one would configure Machinekit to drive motors (with or without encoder feedback) and read sensor data. Then get the motor feedback and sensor data back to ROS via topics.
Depending on realtime constraints / hardware one could write a component for fast control (in MK, not in ROS), and publish info back to ROS.

iluetkeb · 2017-11-15T08:35:15.707Z

Driving the motors is done by dedicated micro-controllers, at least in the systems I work with. Simple ones take velocities and perform PID control, better ones do Model-Predictive Control (MPC). Often, IMUs are also often directly attached, as they are cheap enough for a while now to be just integrated on the board. Of course, for MPC and for IMU integration some configuration is necessary, but not a lot.

I’m not sure what role MachineKit would play in such a setup. Would you use MachineKit to generate the software running on the micro-controller?

warp1337 · 2017-11-15T08:49:26.429Z

What about more complex systems, e.g, whole body motion as in humanoid robots? In order to achieve this, the motors need to be synchronized (I assume), this would require lots of configuration I guess?

basdebruijn · 2017-11-15T10:05:37.252Z

iluetkeb:

I’m not sure what role MachineKit would play in such a setup. Would you use MachineKit to generate the software running on the micro-controller?

Machinekit would either have software step generation (with RT-PREEMPT) kernel, or depending on platform the hardware taking care of this by PRU (microprocessor) on a Beaglebone, FPGA on a mesanet pci card / De0 nano soc.

warp1337:

In order to achieve this, the motors need to be synchronized (I assume), this would require lots of configuration I guess?

As long as you have the motors driven from the same board this is not really a big thing because you’d have the interpolation done by a HAL component. Then the HAL component sets the velocities, etc. Where movement (rough interpolation) is planned by ROS.
Synchronized moves from different Boards is not available (not yet anyway; execution of the HAL function thread needs to be done from an external source (like a hardware interrupt from fpga), there’s been a bit of experimentation with NTP server in the past, but I don’t know the details)

iluetkeb · 2017-11-15T11:16:18.658Z

basdebruijn:

software step generation

I’m not sure what you mean by “step generation”. The motors we use can either be driven by Pulse-Width Modulation (PWM), and most micro-controllers for this purpose do that in hardware based upon a defined level.

Given that the exact API on how to set the PWM is MCU specific, I wonder how “generic” MachineKit would be. Also, given that the code for this is largely trivial and consists out of writing an input value to the right output register, I wonder what benefit is to be gained from MachineKit.

basdebruijn · 2017-11-15T18:44:17.375Z

iluetkeb:

I’m not sure what you mean by “step generation”.

That’s an example of a component for a step generator for a stepper motor. You’d set velocity or position and stop caring about generating steps (let the hardware deal with that), or use PWM, or getting a velocity/position from encoder for that matter.

iluetkeb:

I wonder what benefit is to be gained from MachineKit.

re-use of a configuration (read control system) on different hardware
use components (filters, PID etc) to configure your realtime control behaviour
defined interaction between realtime and non realtime

Lagan_Kapoor · 2017-11-16T09:46:02.307Z

@davecrawley may u suggest me a way to interface ROS with Arduino so that i can make a robot with my own .

Myzhar · 2017-11-16T10:35:53.624Z

Hi @davecrawley ,
I like your answer because you think exactly as I do. I’m a computer engineer, I follow ROS since its first versions but I was skeptical. I’m a Computer Engineer, I can write software very well, I want to do my own framework for my robot, I do not want someone doing this work for me… this was my opinion.
I spent two or more years to write my own software for an autonomous ground robot, and it worked … more or less.

There was a big problem with my work: I WAS NOT MAKING ROBOTICS, I was making Computer Science!

I figured it out, so I decided to move to ROS and in less than a month I reached the same level of work I did in two years and the next month my robot reached a level not minimalally comparable to 3 months before.

So Why do I use ROS? Because I want to make ROBOTICS, I want to concentrate on Robotics tasks, I do not want to spend time writing a wonderful TCP/UDP protocol, creating awesome message structures, thinking about amazing software infrastructures, creating debugging tools.
I want to study Computer Vision algorithms, Artificial Intelligence paradigms, Intelligent Navigation Behavior. This is what ROS allows: WORKING ON ROBOTICS

So, to reply to the question of this thread: “Why don’t we use ROS?” “Because you like to reinvent the wheels”

Walter

firesurfer · 2017-11-17T11:43:29.041Z

I think that is kind of a harsh answer. In general you are right, ROS enables you to do a lot of task faster, but there are also a lot cases where ROS isn’t the solution. (A lot of them are mentioned before).
Furthermore a robot consists of many more parts than just software running on a computer that is able to run ros. Especially in combination with low level software parts that are best to be run on microcontrollers ROS has still many deficits (or you don’t want the overhead of ROS on a bare metal controller)

Myzhar · 2017-11-17T13:20:25.942Z

Well, I agree with you, ROS is not done for microcontrollers (waiting for ROS2…), but low level modules normally have their own firmware and a “simple” communication protocol easily “translatable” to a standard ROS topic. I think that you can agree with me if I say that it is easier to write a node as a device driver if you have a standard way to interface it to the rest of the robot framework.

firesurfer · 2017-11-17T13:48:26.115Z

By doing this statement you are ignoring a whole lot of realtime scenarios. But yeah. For many cases it will be easier to write a node as a device driver.

The only thing I want to say in total is that neither ROS nor a self written monolithic software is the one and only solution.
There are enough cases to justify your own software stack but if you want your system used by others you will need a ROS interface.

Chris_Albertson · 2017-12-13T21:32:57.087Z

In the case of a high DOF robot, like say Boston Dynamic’s “Atlas” humanoid robot. One could use Machine kit to synchronize the two to three dozen motors. What MK is good at is running many axis n synchronization to hit trajectory points in “n-space”. It abstracts the differences between types of motors.

In a typical application of MK user cars about tolerances of 0.0005 inches. Think about a 5-axis milling machine that is making something like a turbine fan blade. It is making very smooth compound curves

What MK adds to a robot is the ability to synchronize moments to the millisecond or better level. ROS is not good at this at all

Here is an application. Let’s say we want to make amble robot is play “dodge ball” with a group of humans. The humans have baseballs and through them as fast as they can at the robot. The robot has to avoid being hit. ROS would fail at this. Message passing is simply to slow. You need a controller that can do sub-millisecond level.

The reason MK can work so fast is it does not use massage tasing. There is a control loop that runs off an timer. Lets say it is a 1KHz timing that causes an interrupt. The output control voltages to every motor in calculated inside that loop. It’s a fast servo controller.

To interface MK. ROS would compute a trajectory through space and specify some velocities to be hit at points along that path. MK would then do the microsecond or millisecond level calculations to force the robot to the specified path and velocity.

The curent meth is that the servo control loop is closed inside ROS and corrections are send as messages to motor controller. This is to slow. Using MK would close the servo loop inside the 1KHz loop. (or there 10KHz loop if you had a fast enough computer.

Chris_Albertson · 2017-12-13T21:42:30.453Z

The approach is different. Has motors have interface to accept commands and ROS can send commands. But the control loop is still closed inside ROS.

When I say control loop I means the one that is looking at error in the 6 DOF arm’s end position. ROS looks at this error then sends message to each motor controller. Machine kit does this calculation inside a lop that runs 1000 or more times per second.

A good division of labor might to have ROS send a message like (go to x,y,z with orientation a,b,c) and ROS might update this 10 or 20 times per second. Then MK was direct control of all 6 motors in the arm and update the motor control signals 1000 ties per second. MK is not just a dumb motor controller. It can compute the kinematics and plan a way to correct error in the trajectory

Again the defiance between using 6 motor controls and ROS vs. using MK is that MK can do kinematics.

machinekoder · 2017-12-17T16:32:37.244Z

Long story short, Machinekit would replace the “Arduino part” in current setups. Namely, everything that relates to low-level motion control such as for example servo loops.

As for distributed setups with “smart” motor drives you should neither use ROS nor any other best effort based system. For this part, I would suggest using CAN, FlexRay or any other Fieldbus system designed for this task.

How would Machinekit come into play in this scenario? Well, one can add a driver (a well defined software component in Machinekit) for the XYZ bus system, proprietary protocol or whatever necessary to control the drives.

Why would you do this? That would make replacing the entry-level PWM based RC servos with industrial grade closed-loop servos controlled via a Fieldbus as easy as pie. Think about a small prototype or educational robot vs. a big industrial robot out in the field. Imagine both driven by the same HAL layer without requiring to rewrite the whole low-level system.

bmagyar · 2017-12-18T15:52:02.205Z

A friend of mine put together his custom motor controller boards on a revived industrial robot. He considered both LinuxCNC and ROS, decided for ROS in the end as that way he could pull off more high level demos with MoveIt. His low-level control is through a ros_control layer.

Btw I’m one of the maintainers of ros_control feel free to reach out by email.

TheConstruct · 2018-01-11T07:28:23.147Z

At The Construct, we have published an article expressing why we do not agree with the post. Too long article to copy it here, let me share the link: On not using ROS for your robotics startup.

We’ll be happy to read your comments.

mlotfy · 2018-01-12T19:43:22.757Z

I am new to the Robotics space, still in the early learning phases. I knew that ROS exist, but I always thought it is very advanced for me due to its very steep learning curve. I decided to build my first real mobile wheeled robot from scratch, in the process I found my self reinventing many trivial things, I discovered that I could have spent that time learning ROS instead. I immediately abandoned my wheel reinventing projects and started the tough learning process. I have to admit that it really paid off. For me, ROS = tooling + community support and for someone new to the field like me, those 2 are priceless.
I believe ROS2 is the answer to most ROS1 shortcomings. The biggest focus is making ROS2 industrial grade with all of its implications. Unfortunately, ROS2 is still in the make and will take time to be ready. Most ROS1 package maintainers are waiting ROS2 to be mature enough to begin porting. Those complaining about ROS1 should skim over ROS2 design whitepapers here http://design.ros2.org/ they may find what they are asking for.

rgariepy · 2018-01-12T21:29:42.525Z

Welcome to the community, @mlotfy!

Oble1982 · 2018-03-21T20:49:29.088Z

thanks a lot mlofty, i want to ask you if we could talk privately as i have some questions? i see the post was in January and i would really like to know if you’re still around.