Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Robot Operating System – A flexible framework for writing robot software

ros.org

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Robot Operating System – A flexible framework for writing robot software

#21

Post by TickleSteve »

lnsru wrote: post #17

Could somebody, please, explain me what I need in addition to ROS for functional safety. Some certified laser scanner? Do I understand it right, that ROS completely ignores functional safety?

If you're meaning trying to create a safety-related or safety-critical system then the particular set of libraries you use is one very small part of the problem.

The system design itself is examined as well as how it is implemented. The examiners will want to see proof that your system fails in predictable and deterministic ways suitable for their usage.

Also systems dealing with the motion-control typically require hard-real-time response so you would not be running this on your average Linux system either.

You need to be prepared to have your code and system design examined in great depth, a very long and expensive process generally.

Re: Robot Operating System – A flexible framework for writing robot software

#22

Post by ragebol »

protomikron wrote: post #16
ragebol wrote: post #14

Earlier quoted context omitted.

The build system is mostly macros on top of cmake. But not ideal indeed. Same for the IDL. ROS 2.0 [0] should adress a lot of those issues, also stuff like real-time, improved security, no roscore needed. On the robots I worked with, I never missed any of those features, to be honest. Largest project of those is a research home service robot, quite different from a self-driving car in terms of reliability requirement…

> The build system is mostly macros on top of cmake. That makes it even worse. So it's crap on top of crap. CMake is mostly used to build cross-platform software, but I don't think anybody uses ROS on a system other than Linux, so why not just use established tools like simple `make`?

I think CMake is quite established. I don't like these kind of holy wars (I like vim too :-)) but to get stuff done. ROS lets me do that.

I've seen several times that companies write their message passing stuff on top of ZeroMQ, mttq and what-have-you, while they could have spent all that time doing something novel as well. At the cost of using less than perfect tools made by someone else that a lot of people are also using.

Re: Robot Operating System – A flexible framework for writing robot software

#23

Post by lzr_io »

lnsru wrote: post #17

Could somebody, please, explain me what I need in addition to ROS for functional safety. Some certified laser scanner? Do I understand it right, that ROS completely ignores functional safety?

ROS is not a suitable tool at all. Functional safety is a totally different beast and SW is only a small part of it.

Don't even think about implementing functional safety on your own without a few years of practical safety experience. Even if you get your hands on all the required hardware parts, you will need to spend a lot of time on making sure you tick all the boxes in relevant standards and convincing notified bodies you did your homework. Don't try to do this on your own, hire an experienced professional right from the start of any project which might touch on functional safety.

Re: Robot Operating System – A flexible framework for writing robot software

#25

Post by Davidbrcz »

protomikron wrote: post #12

My experience with ROS has been suboptimal. It's a collection of incompatible, outdated and buggy tools that communicate with each other via a single-point of failure (roscore) using a pub/sub mechanism. Furthermore they use their own build system (catkin, WHY?), define their own IDL (WHY?), use their own dependency system (rosdep, WHY?) and even mess with your Bash environment. I appreciate their effort and it is re…

I spoke Mikael Arguedas at the 2018 French ROS days (JONAROS) where he gave a presentation about ROS 2 (talks are available online IIRC, in French). During his presentation; he said that most of ROS 1 was engineered before any of today's well known frameworks were available , hence the lot of custom tools. That has driven a major part of ROS 2's design (especially the use of DDS).

Otherwise, I have been personally using ROS for building robots for the French (and European) robot championship (see https://twitter.com/AIGRIS_Birds). It works pretty well, it is convenient, easy to learn and provide some nice tooling (bagging for replaying messages, simulation with Gazebo...).

It is the de facto standard for robotics middleware for scientific projects. It not widely used by industrials because of some shortcomings even if initiatives like ROS Industrial and ROS 2 will likely improve things.

Re: Robot Operating System – A flexible framework for writing robot software

#26

Post by lzr_io »

TickleSteve wrote: post #21
lnsru wrote: post #17

Could somebody, please, explain me what I need in addition to ROS for functional safety. Some certified laser scanner? Do I understand it right, that ROS completely ignores functional safety?

If you're meaning trying to create a safety-related or safety-critical system then the particular set of libraries you use is one very small part of the problem. The system design itself is examined as well as how it is implemented. The examiners will want to see proof that your system fails in predictable and deterministic ways suitable for their usage. Also systems dealing with the motion-control typically require…

Note concerning the system: you will most likely need dedicated, redundant and/or diversified HW all the way from sensing over computing down to the actuator system. At least for industrial robots and cobots, not sure about social robots and such.

Re: Robot Operating System – A flexible framework for writing robot software

#27

Post by roland35 »

lnsru wrote: post #17

Could somebody, please, explain me what I need in addition to ROS for functional safety. Some certified laser scanner? Do I understand it right, that ROS completely ignores functional safety?

The best thing to do, if you can, is to isolate all functional safety related hardware and software to a smaller and simpler subcomponent of your entire system. Then you can prove that no matter what ROS does, it cannot cause harm. This also makes it easier to be certify since your safety related functions are isolated and hopefully smaller and simpler!

Re: Robot Operating System – A flexible framework for writing robot software

#28

Post by asd4 »

protomikron wrote: post #12

My experience with ROS has been suboptimal. It's a collection of incompatible, outdated and buggy tools that communicate with each other via a single-point of failure (roscore) using a pub/sub mechanism. Furthermore they use their own build system (catkin, WHY?), define their own IDL (WHY?), use their own dependency system (rosdep, WHY?) and even mess with your Bash environment. I appreciate their effort and it is re…

> Furthermore they use their own build system (catkin, WHY?), define their own IDL (WHY?), use their own dependency system (rosdep, WHY?) and even mess with your Bash environment.

I agree. When I ask these questions (we use ROS at our company) the answers usually sound like the following:

1. Catkin: No other solution for multi-project CMake. Apparently development often spans multiple projects / repositories for a single integrated "feature" on the robot.

2. IDL: Because they have their own middleware. I think this goes away in ROS 2.0 as they move to DDS.

3. Rosdep: Because they want to run on multiple distributions even though it seems Ubuntu is the only truly supported distro. Rosdep is just a thin layer over the local package manager, pip, and whatever else they have glued in.

4. Environment: They provide the concept of "workspaces" to enable checking out source for a small subset of packages to work on and override whatever is installed on the base system.

I live in the embedded / hardware world but my colleagues working on the higher level software tend think all of the above is necessary for dealing with the hundreds of packages and dependency hell that come with the "modular" robot software approach.

That said, the popular packages in the ecosystem for simulation, planning, robot modeling, etc seem powerful. Community developed ROS "drivers" (middleware integration) are also useful so you don't reinvent the wheel for off the shelf hardware integration.

Re: Robot Operating System – A flexible framework for writing robot software

#29

Post by Scea91 »

amarant wrote: post #11
Scea91 wrote: post #9

Earlier quoted context omitted.

Ive done my bachelor's thesis in 2013 on this. We were working on a robot built for exploration of disaster sites (earthquake, fire, ...). I built: 1) Virtual camera: The robot was equipped with 6 fixed cameras. You can position virtual camera anywhere in the coordinate space and it constructs it's image with the information from the real cameras. 2) System for semi-automatic external calibration of cameras from LIDA…

that's pretty cool! I'm particularly interested in how you made the virtual camera work? can I read your thesis, or (dare i ask) source code?

The virtual camera vas done during summer project but the idea IIRC is quite simple.

I will try some hasty writeup ;)

1) Create a virtual image plane (or cylinder/sphere for panoramic camera) in the 3D space. For this you need to specify the virtual camera's position, orientation, focal length and FOV.

2) Define pixels on the image plane. You need to specify the image resolution and just create grid on the the image plane. Each pixel corresponds to a 3D point in the world coordinate system.

3) To get a color of each pixel you project it's corresponding 3D point to all real cameras. Usually only some of the cameras see the point. Each camera that sees the point gives you a color according to the color of the pixel in it's image. You have to perform blending of these colors. What worked well in our case was to give more weight to cameras where the point projected close to the center of their image.

As you can see, there will definitely be some artifacts, usually more the farther away the virtual camera is from the real cameras. However, it worked to my surprise quite well. It was even possible to look at the robot from 3rd person even though all of the real cameras were on it.

Also it is crucial to have well calibrated cameras. Apart from their projection matrices you also need to consider their radial and tangential distortion which was very significant with our camera models.

https://www.wikiwand.com/en/Pinhole_camera_model

https://www.wikiwand.com/en/Camera_matrix

https://www.wikiwand.com/en/Distortion_(optics)

Re: Robot Operating System – A flexible framework for writing robot software

#30

Post by TeMPOraL »

rcxdude wrote: post #8
matthewmacleod wrote: post #6

Earlier quoted context omitted.

It's a huge ecosystem of components, but from what I understand it's pretty ubiquitous in the research robotics and commercial space. My startup is using it to power an autonomous customer service robot. ROS modules handle things like pose calculations, trajectory planning, collision avoidance, and basically all other interaction between software and hardware. From my perspective as a developer on the user-facing sof…

Yeah, ROS is a very good example of worse being the enemy of good (to mangle some sayings). It's a common framework which does basically everything you'd want to do in a robotic system, with a bunch of useful functionality on top of it, but basically every part of it is incomplete, poorly documented, awkwardly designed, and buggy. However, since there's basically nothing else which addresses the same space, people fe…

So basically, ROS is the UNIX of robotics (i.e. "worse is better", + judging by how many serious projects using it are mentioned elsewhere in this comment thread)?
Post reply on HN