You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently implementing a diagnostics node. (As you might have guessed from the other issues).
At the moment the GPIOController simply doesn't report anything when run with fake/mock hardware as far as I can tell.
It would be nice if it would report:
Robot Mode: Running
Safety Mode: Normal
Program State: true (running)
A) The GPIOController needs access to the information if it is running with mock hardware and could adapt the status report accordingly
B) It is apparently possible to use: fake_sensor_commands in order to provide arbitrary information on state interfaces. When launched with mock hardware we could make sure that the states listed above are set to the corresponding state interfaces.
The text was updated successfully, but these errors were encountered:
That sounds like a reasonable thing to do, thank you for the issue. Intuitively I would say that fake_sensor_commands should be the way to go.
For anybody who wants to implement this: We plan to separate the GPIO controller a bit in the near future, so implementing this feature in an own controller might make life easier.
Feature summary
I am currently implementing a diagnostics node. (As you might have guessed from the other issues).
At the moment the GPIOController simply doesn't report anything when run with fake/mock hardware as far as I can tell.
It would be nice if it would report:
Robot Mode: Running
Safety Mode: Normal
Program State: true (running)
Related issues
#974
#973
Implementation
There are two ways to implement this:
A) The GPIOController needs access to the information if it is running with mock hardware and could adapt the status report accordingly
B) It is apparently possible to use: fake_sensor_commands in order to provide arbitrary information on state interfaces. When launched with mock hardware we could make sure that the states listed above are set to the corresponding state interfaces.
The text was updated successfully, but these errors were encountered: