Plan9/Minix? (previously known as "ROS as in ros.org - What's the produce?")

[Djoga'Ro]

I'm trying to wrap my head around, what ROS is - or rather what it comes up with in the end. I've got so far, that it's a framework to compose my robots software with. I shall install some ROS distro on my desktop machine, start describing my robot in XML - its physical attributes, its sensors, its actuators and whatnot - than write code for nodes, which handle a sensor/actuator each. I've got that they employ a subscription model message passing scheme. Then I've gotta build upon that, while I've got thousands of libraries at my disposal with functionality for perception and orientation, pathfinding and movement and manipulation.

Let's say, I did all that and whatever I did not mention, and I build a robot .. like physically. That damn thing doesn't do anything. Something's amiss. Yes of course. What runs on the robots hardware? Probably I've cought an investigation skill debuff, but I cannot for the life of me find out, what ROS produces. Does it throw up the code for an init and a loop function to be used on a microcontroller, or some software packages to be installed in the robots OS, maybe even expecting Ubuntu on the robot? (When they say on which Linux distros it works, Ubuntu seems to have been the first fully supported one. I sincerely hope they're only referring to the desktop installations.) Since ROS is called middleware, I'd rather expect the latter.

Has someone experience with ROS and can tell, what software may be needed on the robot to run whatever ROS produces, and what it is, that ROS produces?

Reason for my asking is, that a friend, who's an engineer for nautical tech and wants to build submarine robots, which shall be able to go several km deep, asked me, if ROS might be a viable option for making it go. So far I'm not yet convinced, considering that high reliability and fault tolerance should be a top priority and regarding ROS I haven't read anything concerning those goals. If ROS requires the robot to run Ubuntu though, the answer'd be easy. Anyone interested in constructing a Franken-OS Plan9/Minix?

 

[FBnil]

The requirements are here (from there you can extrapolate that it, indeed, should work on other Unixes):
https://www.ros.org/reps/rep-0003.html#melodic-morenia-may-2018-may-2023

If you are going ARM, these boards are supported:
https://wiki.ros.org/hydro/Installation/UbuntuARM

It produces C++ or Python...

#include "ros/ros.h"

or

import rospy

which, I guess, you can compile and then run on a minimal system... (i.e. without X)
Due to the client-server nature, you can degrade (for example, if you have 2 arms, and one fails, the other should still be able to move). As for stability... not sure, it has been a while (a few jobs ago, this other department did things with it, and I was showcased a greeting bot)

https://answers.ros.org/question/46681/how-stable-is-ros-for-long-term-operations/

here is a good read about dependencies and howto start:
https://answers.ros.org/question/119716/install-ros-on-centos-6/

 

[Djoga'Ro]

Thanks @FBnil. The first link looks to me as if they rather refer to the dev-stage-desktop site as opposed to the robot site <= package requirements like cmake, qt, gazebo (simulation framework/environment). And I somehow only found something like that
But the second on looks more like robot site, though. That be a recommendation against then. While the robots are meant to be inexpensive in the context of that market, the missions they're supposed to go on are surely not, and with the bot 3 miles below it would be rather unfortunate, should some driver think to itself, I always wanted to know how it feels to dereference a Null pointer. So however low that chance, it shouln'd be able to take the system down.

But good to know, that one could use ROS just for the high level stuff in combination with another suite for a more reliable base. (According to the latter two links.)

 

[FBnil]

@Djoga'Ro That mission-criticality will have you thinking all kind of crazy scenarios, because the software should be able to cope and react.

TL;DR: It's hard to make good software. Good luck!


For example:

The emitter that handles the pressure in bar suddenly slides from 4 bar (+- 40 meters deep) to 2 bar. If you have 2 probes, you could test the difference between them, and mark the one that shifted as unreliable, maybe even recycle power to it in the hope it fixes itself, and continue with only the "good one".
If you have not, then because the system thinks it is rising, it would release air to lower the buoyancy. But it could happen that a, say, shark takes the submarine in its mouth and moves up very quickly... so do you trust the probe, or the software?
If you only have one pressure probe, you could use the luminosity in the camera to estimate depth... but if it was swallowed by a whale, then it's suddenly dark, so that algorithm will say it is very deep. And if the camera can rotate, well of course if it is pointing up you have more light, so you also need a function that factors in the angle from the camera, but also from the sub.

Then, the software could misbehave, like using up 100%CPU. So you start all processes with cpulimit (or use a RTOS)

Houston in the blind: Protocol has it that you still talk about your actions even if Mission Control contact is lost; just in case it's one-way damage in the communication.
I don't remember the name of the satellite, but it had solar power charging failures, and the non-essential software could not run due to low battery power. So it rebooted a few times, then finally shut down and it was retried from time to time (all in software). Then, once the power of the slow-charging cell was sufficient, it was started again and a photo was send back to earth.

Your central system should also not be afraid to do a complete reboot (automatic panic/total reboot), if say, the engines do not work and/or more that x% of the system is not responding. Test how long a reboot takes, because the sub could go too low and be unable to return.

I you use ROS, you can force a restart of the subsystems in the scheduler (only one uniquely named component can run, so as you start a new instance, the old one should disappear. If not, kill -9 it (and warn about it) ). Have one component be just an emitter (for example, connected to the internal clock, an almost guaranteed update and very reliable), and if the central Publisher is not logging what you emitted, it is time to kill the Publisher, and you need that in a .sh script that loops, or Init.d respawn or if systemd is there, an Restart=on-failure... maybe with a cpulimit command after they start.
Does it need to have a second Publisher head that takes over after 5 minutes of inactivity of the first? And is the behavior the same? Or different (come back up to the surface). One emitter could be checking the battery output, if dropping too fast or too low, reduce maximum speed, or disable arms (just like the Pandora, where you can disable USB ports... well, our only USB port, and lower the power drain), etc.

Then you will need calibration. How much power does it take at x depth to open the air cannisters and make that particular configuration of sub buoyant? (if you mount extra stuff, do you need to recalibrate that?). So once you do those tests, you have a minimum battery threshold where you can decide to go into panic mode and auto-resurface... or not and let the cable be strong enough to lift it back to the ship.

 

[Djoga'Ro]

@FBnil Si Senior. That's why I find Minix' premise so promising. A very small trusted code base. Among it a resurrection server, which pings system processes (drivers, fs-servers etc) and, when they're not well/answering, it kills them and starts them anew. And since some, if not alot, drivers might be needed written in-house, they couldn't be as trusted as ones, that have run on millions of devices in many different configurations. Plus I've been told user-mode drivers are easier to develop, for easier debugging and binary replacement.
And now think, you'd breed Plan 9's 9p aspect into the mix, which expects drivers and servers to be interfacable like file servers - trancsparently over network connections. So after some manageable initiation your brainy process on some network node can handle all the sensors/actuators via local(-looking) file io - same at your workstation if you run Plan 9 or (jre-like) Inferno. So, via means of the OS you'd already get the base, ROS brings you - short of the prescribed messaging protocol's default messages (and style?). Meaning the latter you'd have to define and adher to on your own.
Woulnd't that be sound grounds to build upon, letting you mainly focus on the application side and think about possible reasons for stragne sensor readings and such.

Damn it, I'm dreaming again. Sry.

I guess, what I needed to get off my chest is, Why ain't there no Plan 9/Minix?

 

[FBnil]

Damn it, I'm dreaming again. Sry.

Brainstorming <> dreaming. So don your Software Architect hat and design.
For the IF scenarios, write them down. Write it all down because you need to think about how the software should react. Sometimes, the right reaction is to not react, but at least you thought about it beforehand. Just like charging the Pandora with barreljack and miniusb... how should the circuit behave. Make a list of data you have. The hardware temperature, the powerdraw, etc.

 

[Djoga'Ro]

First I'd need to earn me such a hat - at least the low level stuff and the system initiation stuff variants. Those stuffs intimidate me terribly - especially the latter.
I guess studying Minix' small trusted code base would be a start.

 

[levi]

I'm not sure anyone's claimed that the Minux kernel can be trusted, although to be fair I've never read Tanenbaum's book on it. The pure microkernel is trustable perhaps, due to being small and so possible to be seriously reviewed and even patched, but it'll have a whole host of userspace drivers handling keyboard and mouse events and USB ports and all those kind of things. And if you feel like reviewing all of the clang+llvm code then feel free, but I wouldn't advise it.

 

[Djoga'Ro]

His main focus is on reliability in the sense of fault tolerance - like if a driver or service fucks up, restart it and keep going. The base components for that is what he calls the trusted code base, i.e. the smallest subset, in which you have to put your trust or which must be trustworthy. So that needs to be kept small. It entails the kernel, the user-mode resurrection server, which pings the driver and server processes and kills and resurrects them, and some other user-mode process, which doesn't come to mind. Last I heard it was 15 kSLOC. How big are modern monolithic kernels again?

All that separation also caters to other security aspects. I don't know, how Minix handles namespaces in regards to processes. In Plan 9 every process defines/builds his own namespace, while the initial part is given by the parent process as I understand it. So a process can put whatever resource's file representation he likes into his personal view of the directory tree, as long as he's permitted (per resource).

And you're right, I'll also have to earn a compiler stuff variant of a Software Architect hat. This would-be-project touches on lots of fields of expertise quite intensely. But the thought of maybe there being something like it someday, that I could put on all of my devices - from the router over desktop and Pyra to NAS and whatnot - and have that fluent interconnectivity, I could make use of from the console via echo and cat, as a given, makes me all warm and tingly inside.

 

[FBnil]

at least the low level stuff and the system initiation stuff variants. Those stuffs intimidate me terribly - especially the latter.

Hey, me too I still have a project on hold because I'm afraid to fry the components.

Here is somebody that exposed the GPIO on a BeagleBoard to Minix3, working code:

Final presentation:

http://minix-i2c.blogspot.com/


More of the basics:

 

[ible]

speaking of microkernels, sel4 is one (https://sel4.systems/); i think their license is a bit better than minix IIRC.

probably the difficulty of interfacing with a "strange" system (e.g. minix, sel4, plan 9) will also involve some mental overhead. the Windows <-> Linux boundary is "easy" to navigate after all these years, but it may be more difficult than you expect to do even simple things on a simpler OS/set up. love to be proven wrong, of course.

 

[levi]

Minix since version 3 or thereabouts came with X windowing included, and that should allow you to use some of the same DEs you use on Linux and BSD I guess. But yeah, plan 9 takes a bit of head scratching to me still, and I've not played with sel4 yet.

 

[Djoga'Ro]

When it comes to Plan 9 I've actually only read about it and read some rationale about some aspects of it. So far I've got the picture, that they didn't like - with the original philosophy in mind - what UNIX had grown into and did a do-over. From what I've seen Plan 9 seems even easier to use, everything more straight forward and coherent and more thoughtfully designed. I'd rather stick with that and ditch POSIX in my thought-up frankenOS. I might be wrong, of course.

 

[Linux-SWAT]

No, Plan9 isn't easier to use.
First you have to use a mouse again :^)

 

[Djoga'Ro]

The user can't change the components, that bring this mouse-drivenness?