Vehicle control protocol/API #291
Labels
enhancement
New feature or request
planned
Likely a requirement for a 'final' product
question
Further information is requested
Problem: vehicles have lots of controls and readouts
Space Shuttle Cockpit. Svobodat, CC BY-SA 3.0 link
what should we do? numbered action groups? nah.
OSP already features a system that practically a works as a logic circuit simulator (TODO: documentation required, though Longeron++ circuit simulator example works in the exact same way). Vehicles can have arbitrary switches, joysticks, throttle sticks, etc... as well as PID controllers and sensors.
The vehicle test scenario uses a "UserControl" Machine, which acts like a circuit component that doesn't do any processing but has outputs for throttle, yaw, pitch, and roll (see code). The
setup_vehicle_control
session allows a running window application to select 1 UserControl Machine to write keyboard inputs into.This works as a great starting point, but is currently a temporary solution. There's a few other things required:
setup_vehicle_control
session acts like glue code between the OSP world and the window application. It directly reads/writes from both. A more finalized UI can do this as well, but it would be kinda ugly imo. There is nothing another extra level of indirection can't fix: a finalized UI can output and receive a stream of messages through whatever means without needing to directly read/write into the OSP world.A protocol/API has other benefits:
Controlling a bunch of little beep boops is already a solved problem: take a look at MIDI instruments, OS joysticks, or industrial/scientific control systems.
some open questions:
Should it be allowed to switch vehicles or only access the selected one?
The text was updated successfully, but these errors were encountered: