RODOS - Realtime Onboard Dependable Operating System

[J.R.I.B]

[RODOS Grundlagen PDF] (deutsch) What is RODOS? - detailed answer!! (attention huge pdf, and in German!)

Thanks to Thomas Walter and Michael Ruffer in collaboration with Prof. Montenegro the new RODOS now supports Raspberry Pi, (STM32bit) Cortex-M1, M3 and M4.

This is relevant for us, as for example [http://www.tumanako.net/]Tumanako Open Source Electronics for Electric Vehicles[/url] and the very advanced OpenPilot use STM 32bit Cortex-M4 because of its Floating point hardware implementation (if ARM gcc toolchain is used) that makes it capable to process computing intense floating point calculations fluently.


The good thing is, it supports Arduino (AVR in general) devices that have 2 kB RAM and 20 kB FLASH ROM as well as ARMv7 (if I’m not wrong BeagleBone should be covered by that, because Cortex-A7+ should use ARMv7 standard) and many other microcontrollers like Raspberry Pi and even FPGA devices. Now FPGA might be too fancy for us and will cost far too much. DSPs might be an option but we should try to handle big data with as simple solutions as possible.

RODOS has some advantages. With it we can:

• write simple code. (No more fancy and hardware specific usage of TIMER counters that get more and more only semi-useful features that hardly anybody uses and only makes it complicated and incompatible with other vendors.)
• write portable code.
• change the microcontroller on the fly without changing the software.
• no longer have to bother about how this dang register
• no longer have to fear the easy conflicts and general mess that occurs in c-type procedural realtime operating systems like RTOS (nothing against RTOS or C, I like it and use it, but it’s a mess for big projects - that’s because can’t encapsulate your data properly and still keep your methods accessable the same way like the attributes. And honestly if we compare Assembly with C and then with C++ - is there really so much more abstraction? Is C++ so much a higher level abstraction that it’s suddenly evil? C is cool, but C++ is much more reusable and what open source needs is proper modularity and not 4 million redundant teeth brush machines for which each developer had to spend so much time in solving already solved problems. We have a lot more to research, there is no time to reinvent the wheel each year unless you explicitely wish it because you’re a geek and nerdy and have nothing else to do. Don’t take it personally, I meant it as a critics of modern society.).
• no longer have to deal with the realtime problems of UNIX operating systems (eventhough a realtime GNU/Linux kernel would be brilliant!).

What it will not relieve us from:

• Knowing the hardware by heart to always remember which pin is actually connected to what.
• Reading the microcontroller datasheets because when debugging RODOS applications it might well be that you step into the assembly code or at least want to see what is going on in the hardware layer. Noone is safe from bugs, so is RODOS.
• Using all our creativity to create something fancy out of the simplest things. It’s just about making the Open source community more compatible.

I don’t know if you like it, but if you like then use it. I will develop and put up online (as RODOS is Open source) example projects as quickly as is possible to drive EDUWAFA & AMOR forward. Unfortunately for now one has still to ask Sergio Montenegro for the Source code as he wants to know what people do with it and who it does. You can also ask DLR but you will end up with Prof. Montenegro anyway. (Last year I tested it and asked DLR for the code not telling them that I’m a student of Prof. Montenegro anyway. Then I received an email of the Professor and even the source was attached, perhaps I was just lucky … lol Anyway, they don’t bite, they are good fellows. Unfortunately I’m a bit a black sheep for them currently as I’m not a good student currently - wonder why lol, something must distract me, I don’t know what . Irony off No, i’m open source and it’s no secret: The teacher’s project has knocked me off for much too long a time and I am missing 2 ECTS points and my thesis (guess, the Teacher’s project should have been my topic but there are difficulties now and this shocked me, so I have to work out two theses simultaneously) to finish those crazy studies. Luckily last week I had a severe breakthrough in the Teacher’s project and even though that was a late relief and it unfortunately still is not finished completely and I begin to wonder w h e n this sad crazy mission impossible will finally end.)



Okay, now you enough of my humble self. Now perhaps you understand my byname Radagast, my friends have reasons for that … lol


More information about RODOS:
http://en.wikipedia.org/wiki/Rodos_(operating_system)
http://dlr.de/irs/desktopdefault.aspx/tabid-5976/9736_read-19576/
https://wuecampus2.uni-wuerzburg.de/moodle/pluginfile.php/171744/mod_resource/content/1/033-rodos-grundlagen.pdf

[J.R.I.B]

News:

• RODOS will go Github soon. And thus it will go really open source not much later. That means once the repository is made public, collaboration can start. (And you don’t have to write a RODOS request message to Prof. Montenegro anymore.)
• Das Deusche Luft- und Raumfahrtzentrum (DLR) ist bald auch auf Github zu finden. Nicht viel später wird RODOS dann endlich wirklich alle Quellen offenlegen. (man muss dann also keine Nachricht mehr an den Professor senden, um den Quellcode zu ergattern.)

Käfer selbst beheben oder neue Hardware-Unterstützung einbauen, fortan alles möglich - auch ohne Chaos. (Bisher haben eigene Veränderungen immer zu einem Rattenschwanz an Chaos geführt.)


Entwickler-Neuigkeiten:

• Dank Tobias Mikschl läuft RODOS jetzt auch ohne eigenes Zutun auf BeagleBoneBlack. Der Zweig (mit der BBB zugehörigen Hardware Abstraction Layer (HAL)) ist aber noch nicht ins Hauptrepository gemerged.
• Ein Käfer, der sich im Thread-Timing eingenistet hat, wird derzeit von Erik Dilger verfolgt. Dass das DLR den Bug überhaupt gefunden hat ist good News. Ich denke, es wäre sonst bei AMOR im Langzeitbetrieb zum Stolperstein geworden!
• Michael zieht Raspberry PI mit und hat Probleme im USART gefixt. STM32 bit Microcontroller sind bisher die am besten unterstützte ARM-Hardware.

Edit: Hinweis, warum mich das alles kümmert: RODOS läuft bei AMOR auf dem BBB und auf STM32. Praktisch ist, dass jeder Sensor seine Daten als ein „Topic“ (Thema) veröffentlicht und sich nicht weiter darum kümmern muss, wer die Daten verwendet. Braucht ein Thread die Daten plötzlich, muss man nichts ändern, man muss nur das Thema abonnieren.
Es gibt auch Sensoren die über WLAN verbunden sind (z.B. Sensoren an den Kuhfüßen) - vielleicht verwenden wir Alex’ „Wilssen“ Sensor Module RF24 auf einem Arduino dafür (hier natürlich ohne RODOS).

[J.R.I.B]

RODOS Veröffentlichung steht noch immer aus. Ferner haben die Entwickler mich auf

• UDOO aufmerksam gemacht: (3x so teuer, dafür aber 4x so viel Rechenleistung und GPU, also eine Garantie für die 3D Kamera. Damit wäre der Mikrocontroller allerdings das teuerste Bauteil, noch vor 3D-Kinect, das bei 100€ liegt.)
• Ferner hat das BBB allen Anschein nach ein Problem mit Preemption bei RODOS. Es wird daran gearbeitet. Leider besteht das selbe Problem auch bei UDOO, meine Hoffnung ruht auf Erik, der das momentan genauer unter die Lupe nimmt (es ist in Assembler programmiert, also momentan nicht so leicht zu herausfinden, was schief läuft). Die Abstürze sind scheinbar zufällig. STM und AVR microcontroller sind von dem Problem nicht betroffen.

Die Frage ist, ob man auch zuverlässige hardwarenahe Programme schreiben kann, die trotzdem alle 4 Kerne ausnutzt. Theoretisch ja. Es ist eine Kosten-Nutzen-Frage: Für 3D-Sensor-Daten-Verarbeitung kann sich das lohnen.

→ UDOO OSEG Forum Thema

[J.R.I.B]

Okay, der BBB und UDOO Bug bei RODOS ist behoben. Es war ein Interrupt während eines Kontextwechsels (Stichwort Preemption/Verdrändung). Also ein Kontextwechsel während eines Kontextwechsels. Tobi hatte das bereits vermutet und Erik hat’s gefixt.
Aber das DLR bringt’s einfach nicht hin, Open Source zu gehen. Zu viele Sorgen, dass sie die Verantwortung hätten, wenn etwas schief geht anscheinend.

Okay. Da muss man reagieren:

• Ich setze auf Archlinux für die großen Projekte mit Datenverarbeitung
• in Kombination mit Arduino oder BBB und falls nötig RODOS.
• Die kleinen Projekte (Motorsteuerung) laufen auf RODOS, damit ich mich zwinge, nicht Spezialfeatures von irgeneinem Mikro-Controller-Hersteller zu verwenden. Ist das Bauteil dann erstmal nicht mehr verfügbar, wäre das ganze Programm und die Kalibrierung geeimert. Nein danke.

[case]

@J.R.I.B.

• Ich setze auf Archlinux für die großen Projekte mit Datenverarbeitung
• in Kombination mit Arduino oder BBB und falls nötig RODOS.
• Die kleinen Projekte (Motorsteuerung) laufen auf RODOS, damit ich mich zwinge, nicht Spezialfeatures von irgeneinem Mikro-Controller-Hersteller zu verwenden. Ist das Bauteil dann erstmal nicht mehr verfügbar, wäre das ganze Programm und die Kalibrierung geeimert. Nein danke.

Was war denn mit dem neulich von Dir vorgeschlagenen ROS ? Das sah doch recht interessant aus, fand ich.

Gruss, Oliver

[J.R.I.B]

ROS ginge, wenn es Realtime wäre. Ist es aber scheinbar nicht. Es gibt eine Portierung zu RTOS. Doch wer RTOS benutzt, kann auch RODOS verwenden.

Deswegen: Realtime → RODOS. Daten & aufwendige Algorithmen → ROS.