Layered handling of node and (sub-)system errors
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Inizia leggendo l’issue #43 e la discussione su ModeManager, diagnostica e MROS Metacontroller. Non viene indicato alcun file sorgente né alcun test, e prima di poter considerare conclusa l’implementazione è ancora necessario raggiungere un accordo sull’interfaccia di diagnostica e sul comportamento previsto.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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 ?
- Lingua principale
- C++
- Stelle
- 45
- Fork
- 13
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di micro-ROS/system_modes
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
micro-ROS/system_modes#101 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
micro-ROS/system_modes#99 · 3 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
micro-ROS/system_modes#98 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
micro-ROS/system_modes#97 · 2 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
micro-ROS/system_modes#96 · 2 commenti ·
Tutte le issue di micro-ROS/system_modes
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
objectionary/eo-graphs#74 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 95/100
-
enhancement
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
QuantStack/git2cpp#187 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100