Hi, I want to start a discussion about the optimal implementation of some simple sensing payload (eg. gas sensors - CO, CO2, SOx, NOx, Particle Matter, Humidity, Temperature, … ). These sensors types usually has a possibility to connect directly to the Pixhawk Autopilot hardware via an existing interface (UART, I2C,… ).
Connecting these sensors to the autopilot hardware instead of making a separate payload, gives a possibility to record and transmit the measured data in parallel to other telemetry values (position/time), it also reduces the system weight and amount of work to process the measured data.
There are at least two possible ways how to implement this payload type.
Make a separate PX4 driver for each sensor type
There will be a sensor directly connected to the autopilot interface and the autopilot firmware driver will handle all communication and setup of the sensor. Produces uORB messages to allow logging, then arrange the MAVlink packet from sensor data and transmit it to the ground station.
These payload sensor drivers will be probably a submodule in standard autopilot drivers.
Benefits of this solution
- The lowest mass of payload possible
- Direct integration of sensor drivers and possible cross interaction with other uORB messages containing the information relevant to the payload, at least position, time, velocity…
- Possibility to easily optimize the payload behavior to flight status
Disadvantages of this solution
- Need for specialized autopilot firmware for each payload
- Some modifications in sensor/payload behavior needs recompilation of whole autopilot firmware
A universal driver for payload communication
In that case, the sensor will be connected to some external MCU (Arduino for example), which handles all sensor-specific work and output the measured data in a standard message format. The message format could be:
The autopilot receives payload data encoded in one of these formats, unpack into uORB messages to allow logging. Process the content to the MAVlink message and send it via a telemetry link to the ground-station.
Benefits of this solution
- There is not required to change autopilot firmware in case of payload sensors changes
- The programming skill required to integrate new sensor types is reduced compared to programming direct driver in PX4 firmware
Disadvantages of this solution
- Increased weight and complexity of the system
- Precise synchronisation to other values measured by autopilot could be difficult or imposssble.
The question is - which method will be more probably adopted by PX4 ecosystem and its community?