MRROC++

Obecna implementacja komunikacji ECP<->EDP prowadzi do następującego scenariusza,
który jest potencjalnie niebezpieczny w kontekście SwarmItFIX:

1. jeden z robotów się rusza, a inny oczekuje na zlecenie od koordynatora - get_next_state()
2. Następuje awaria w EDP robota "oczekująceo", dla przykładu:
a) awaria w jednym ze sterowników osi (o czym dostaję asynchronicznie powiadomienie w przez CAN)
b) awaria okablowania CAN (o tym też dostaję info)
c) coś się segfaultuje w EDP (bo to, że robot się nie rusza nie znaczy, że EDP nic nie robi i jest stabilne)
d) ...
3. W tym momencie nie ma możliwości powiadomienia ECP o zaistniałym problemie
(bo ono wisi sobie na oczekiwaniu zlecenia z MP) a w konsekwencji nie dowie
się też o nim koordynator i nie zatrzyma ruchu innych agentów.

Pytanie zatem - jak EDP może zainicjować przesłanie wiadomości do ECP w sytuacji jw.?

Rozwiązaniem jakie ja widzę, to przejście na spójny mechanizm komunikacji, który nie będzie
blokował się na jednym, określonym kanale (czyli tak jak jest to np. w klasie Agent na linii ECP<->MP).