-
Notifications
You must be signed in to change notification settings - Fork 0
Copilots
STARDOS is a modular architecture that is designed to operate on any number of different vehicle designs with various different control systems. The easiest way to ensure that a vehicle will be able to carry a functional STARDOS data collection payload is to install what we call a "copilot" computer into the vehicle's control systems. This computer should run any number of different programs that connect the STARDOS payload's ROS2 network to both the vehicle's control system and the operator control station. These programs are collectively referred to as the "copilot software," and can consist of a number of programs ranging from full-featured ROS nodes to one-shot services that set up networking devices and anything in between.
Without a copilot computer, a STARDOS payload will need to run copilot software itself if it is mounted on a vehicle. Copilot software run in this way may be a stripped-down form, providing only short-range payload telemetry and control, or it may be fully-featured if the payload computer can support a direct interface to the vehicle's control systems and/or a long-range radio.
STARDOS currently has a limited implementation of a MAVLink copilot that receives and rebroadcasts vehicle telemetry on the payload network, as well as relays payload telemetry and commands over the vehicle's telemetry and command link.
A fully-featured copilot has a number of things it needs to do, not all of which are directly related to its primary role as a telemetry and control router. The following sections detail each task a copilot should be capable of performing, along with its importance to the overall STARDOS system.
Probably the most important role of the copilot, as without this there is no way to validate that the payload is functioning properly from the control station. The preferred way to accomplish this task is to route the telemetry through the vehicle's telemetry link, however this will inevitably require custom software to translate and serialize the ROS2 telemetry data. For short-range operation, something as simple as a ROS2 domain bridge operating over Wi-Fi may be sufficient. In longer-range setups without a vehicle or where the vehicle's telemetry link is unusable, using a serial radio directly may also be an option.
This role is critical to a STARDOS system. STARDOS cannot function without it.
Fully Implemented for MAVLink Vehicles
- MAVLink vehicle telemetry relay
- Network relay via domain bridge (cuts out if network is lost)
- Network relay via MAVLink UDP/TCP
- Serial radio relay direct
- Serial radio relay via MAVLink
We may want to investigate additional implementations for other vehicle control systems, but that is not a priority at the moment.
The second most important role of the copilot, as without this the payload cannot be initialized without jumping through hoops. The preferred way to accomplish this task is to route the control signals throug the vehicle's control link, however this will inevitably require custom software to translate and serialize the ROS2 commands, which will need to be repeated for each control system. For short-range operation, a ROS2 domain bridge operating over Wi-Fi may be sufficient. Generally speaking, these signals can be routed over the same link as payload telemetry, as they are smaller and less frequent than the payload telemetry data.
This role is critical to a STARDOS system. STARDOS cannot function without it.
Fully Implemented for MAVLink Vehicles
- MAVLink vehicle command relay
- Network relay via domain bridge (cuts out if network is lost)
- Network relay via MAVLink UDP/TCP
- Serial radio relay direct
- Serial radio relay via MAVLink
We may want to investigate additional implementations for other vehicle control systems, but that is not a priority at the moment.
An eventual goal of STARDOS is to be able to transmit real-time processed data from the payload to the control station. Due to bandwidth constraints and concerns about overloading the vehicle command link, it would be preferrable to implement this using a dedicated parallel radio link regardless of the vehicle design. The advantage of this implementation is that it will work on any vehicle, while the disadvantage of this implementation is that it requires additional hardware, which presents issues for aircraft due to weight limitations. It should be possible to send limited amounts of low-resolution data through a vehicle's telemetry link, but in the author's opinion it should be considered a last resort.
This is a valuable thing to have, but STARDOS will function fine without it.
Preliminary Investigation in Progress, No Working Prototypes
- MAVLink vehicle telemetry relay for low-resolution compressed data
- Network relay
- Serial radio relay
Important for collecting any form of localized data, and should be implemented whenever a payload will be connected to a mobile vehicle. Important telemetry includes location and attitude data, as well as GPS clock time if available that the copilot computer can use to set its clock.
This is required for mobile data collection. GPS time setting is not required unless the system is not equipped with a real-time clock module.
Partially Implemented for MAVLink Vehicles
- MAVLink vehicle telemetry republishing
- System clock setting
- Some questions still need to be answered for this
An eventual goal of STARDOS is to have the payload be capable of uploading waypoints to the vehicle. More details to come.
This will be required for real-time processing and mission planning, but for basic mapping missions it is unnecessary.
Conceptual Stage, No Tasks Yet
Having accurate clocks is important; having synchronized clocks on the vehicle's on-board computers is more important. The copilot, having access to GPS time via its connection to the vehicle control systems, is in the best position to have an accurate clock that can be synchronized to. As such, we may want to run an NTP server on copilots.
This is not required, but may head off issues from earlier
Conceptual Stage, No Tasks Yet
The copilot is in a unique position at the interface between the vehicle's command and telemetry links and the STARDOS ROS network. It should take advantage of this position to produce as detailed of mission log files as is reasonable. Producing separate logs for each system is possible, but ideally the logs would all be unified for ease of access.
Partially Implemented
- Process output logging with
systemd-journald - ROS network logging with ROS bags
- MAVLink telemetry logging
- MAVLink command logging
- Unified logs