Layered handling of node and (sub-)system errors
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Beginne damit, Issue #43 und die Diskussion über den ModeManager, die Diagnostik und den MROS Metacontroller zu lesen. Es wird weder eine Quelldatei noch ein Test genannt, und vor der Implementierung muss noch eine Einigung über die Diagnoseschnittstelle und das erwartete Verhalten erzielt werden, damit sie als abgeschlossen betrachtet werden kann.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
from (#47 )
This is in the context of our exemplary case of the
laser_drivererror. We want to elaborate on the layered approach we discussed in the last MROS meeting. This is how I interpret our desired design (please comment if something is not correct or clear):
- First the
laser_drivercode for handling errors tries to recover from the error in theErrorProcessingtransition state.(from here it is a related but different issue)
- If it does not succeed (I guess that means node does not transition to
Active), theModeManagertries to recover from the error using thefeature/rules. For this, @jginesclavero is adding a rule in the SystemModes file of our system.- If there is no rule, or there is but after applying it the alternative
MODE(s)of thelaser_driverare not reached either, theModeManagerreports to theMROS Metacontrollerthat the corresponding (sub)system(s) MODE(s) are not reachable.
(see issue for the continuation of the handling of errors at the higher layers)
continuation
Currently this will be implemented in a passive way, by offering that information (see https://github.com/micro-ROS/system_modes/issues/43)
But, since the current target MODE cannot be reached... we were thinking (in a discussion with TUD and URJC) if the ModeManager should report this actively system wide, for the operator or any supervisory system (e.g. MROS Metacontroller) to handle it.
Proposal: Since not being able to reach the target MODE is a deviation of expected and desired behaviour, we propose that the ModeManager uses diagnostics to report this. The MROS Metacontroller will subscribe such diagnostic messages.
(@fmrico @jginesclavero @marioney please comment if I missed something or did not convey it correctly)
What do you think @norro ?
- Vorherrschende Sprache
- C++
- Sterne
- 45
- Forks
- 13
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus micro-ROS/system_modes
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
micro-ROS/system_modes#101 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
micro-ROS/system_modes#99 · 3 Kommentare ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
micro-ROS/system_modes#98 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
micro-ROS/system_modes#97 · 2 Kommentare ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
micro-ROS/system_modes#96 · 2 Kommentare ·
Alle Issues in micro-ROS/system_modes
Ähnliche Issues
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
AXERA-TECH/ax-llm#77 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
games-on-whales/wolf#509 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
-
bug-unconfirmed
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100