motor etc auto-off feature

microsoft / jacdac

Device and service catalogs for Jacdac.

https://aka.ms/jacdac

Creative Commons Attribution 4.0 International

66 stars 25 forks source link

motor etc auto-off feature #117

Closed mmoskal closed 3 years ago

mmoskal commented 3 years ago

we have auto-off for streaming sensors (you have to specify number of samples to stream, which eventually expires).

There is no such facility for motor and similar services.

Some users may assume that when you disconnect a brain from motor controller, the motor should stop.

Is this a design pattern we should have in all services?

Brought up by @pelikhan in vibration motor discussion.

pelikhan commented 3 years ago

If you compare jacdac to existing systems (like LEGO), yes everything should auto-off if the brain is crashed. However, for example, for light show, it would be nice to have something that's resilient to the brain intermindently stopping to run.

pelikhan commented 3 years ago

IMO, it would be safer to also expire motor commands.

jamesadevine commented 3 years ago

If I remember back to my Lego mindstorms days, the way I fixed dodgey motor code was by hastily unplugging the motor module from the robot. 😄

More seriously, I think we should be leveraging the benefits of having a microcontroller on every peripheral a lot more than we have been. This auto-off feature could easily be supported/implemented by having certain commands that are tied to the device ID that invoked them. For example, the motor service would remember that device X last issued the "motor on" command, and turn off accordingly when device X emits an error or is removed from the bus by the user.

This auto off feature could also be great for "streaming" services. A streaming service would only stop streaming when the device that issued the streaming command is removed from the bus or emits an error. I think this would also be simpler from the host side to implement as set streaming / set n samples command would not have to keep being regularly re-issued.

What do you think?

mmoskal commented 3 years ago

It would need the following:

the sender device ID in commands (right now only destination is there)
the motor controller would need to store IDs of everyone who have turned the motor on; also there could be no logic in the client like "if the motor is not on, turn it on", as that would be susceptible to some devices turning off

Note that the current implementation of the light service (plus bootloader) already fills 16k of flash. I guess that could be optimized somewhat, but we also wanted a more intelligent light service, and I wonder if we should be complicating things beyond the point where they fit in 16k of flash...

What I was thinking was something simple and generic - a watch-dog feature on the control service. Once you wake it up, you have to keep feeding it packets, otherwise after say 3s it resets. I guess you could also turn it off. I guess even that won't fit with the light service, would have to drop something else.

mmoskal commented 3 years ago

see https://github.com/microsoft/jacdac-c/pull/12

mmoskal commented 3 years ago

This is now fixed