Vehicle control protocol/API

[Capital-Asterisk]

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:

• A way to identify what controls and readouts a particular vehicle has. UserControl Machine can be developed further to allow naming outputs.
• A generic protocol/API to interface with vehicles or UserControl. The 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:

• For development; allow controlling vehicles without needing a UI.
• Easily building external controllers. Imagine making a custom control panel using a webpage or a physical one with a microcontroller. Pipe it into OSP through some means (serial, udp, tcp, websocket, etc...) and have fun!

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:

• Implementation details: hand-rolled bytes? binary-json? Protocol Buffers? Cap'n proto?
• How "omnipresent" should this protocol be? Does it know about all the other vehicles in the world?
  Should it be allowed to switch vehicles or only access the selected one?
• Maybe we should have a protocol to control EVERYTHING: loading world, creating planets, selecting vehicles to launch, etc... Either way, the vehicle control stuff can be nested into it if it ends up existing.