Layered handling of node and (sub-)system errors
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Comienza leyendo el issue #43 y la discusión sobre el ModeManager, los diagnósticos y el MROS Metacontroller. No se nombra ningún archivo fuente ni ninguna prueba, y aún es necesario llegar a un acuerdo sobre la interfaz de diagnóstico y el comportamiento esperado antes de que la implementación pueda considerarse terminada.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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 ?
- Lenguaje dominante
- C++
- Estrellas
- 45
- Forks
- 13
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de micro-ROS/system_modes
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
micro-ROS/system_modes#101 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
micro-ROS/system_modes#99 · 3 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
micro-ROS/system_modes#98 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
micro-ROS/system_modes#97 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
micro-ROS/system_modes#96 · 2 comentarios ·
Todos los issues de micro-ROS/system_modes
Issues similares
-
enhancement
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
QuantStack/git2cpp#187 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
mlcommons/mobile_app_open#1182 ·
-
Needs-Triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
microsoft/winget-cli#6547 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
AXERA-TECH/ax-llm#77 ·