Hardware tuning

This section describes how to tune hardware, connect signals and set-up sensors.

Note

Ususally, if the setting value is zero, the feature considered as turned off.

AHRS

This feature estimates different navigation parameters, based on sensor readings from other modules. The estimations are performed wit MEKF algorithm, and the inertial navigation (in case of GPS lost) is based on airspeed sensor readings and current wind estimator values.

The current implementation is capable to have loop frequency of maximum 400Hz (on AP10). This update rate is adjusted automatically, based on available inertial data rate and is reported to the console.

The source for inertial sensors (acc, gyro, mag, ...) is automatically selected, based on availability, thus making redundancy possible.

The data source is choosen with the following priorities (high to low):

The concept of distributed architecture is followed by the assumption, that all sensors monitor their health and supply data to AHRS if possible. Then AHRS automatically choose the best option and reconfigure itself to adopt to current conditions.

Estimated parameters include:

AHRS tuning:


Airspeed

Dynamic pressure sensor estimates airspeed from pressure readings.

The use of fixed calibration mode is strongly recommended. To perform the calibration, follow these steps:

* Pre-flight check should always include Airspeed sensor test.


Altimeter

Static pressure sensor estimates altitude from pressure readings.

To estimate real noise of the sensor, you may need to temporally setup AHRS as follows:

The raw pressure readings will be shown in *altitude* and *vspeed* variables.

On normal operation, the ouput of the sensor is filtered through AHRS subsystem to provide high precision estimates.


Analog inputs

This feature measures analog voltages (up to 30V) and updates the Mandala variables with configured rate.

Useful for battery voltage measurements.

Options:


Antenna Tracking System

ATS

This feature controls servo motors to point directional antenna to currently selected UAV. this driver works together with Datalink protocol to track selected vehicle and its coordinates.

To estimate the direction, where to point the antenna, this feature uses different sources of information, depending of its availability in the following order:

The following parameters tune ATS behavior:

The motors should be tuned to maintain the speed *atsctr_yaw*, *atsctr_pitch* and output encoder values in *atsenc_yaw*, *atsenc_pitch*.

The ATS is tracking the currently selected in GCU and active vehicle, based on its downstream telemetry data.


Auxilary CAN

CAN2

This feature provides dedicated CAN interface for communication with other (non-AP) devices through Virtual Machine. Although, it still could be used as system CAN bus interface (splitting large networks).

This interface is compatible with Serial Ports concept.


CANaerospace

This feature provides support for CANaerospace protocol.

For physical layer, this protocol uses the same CAN bus as AP system (not virtual port), i.e. both system bus and CANas can operate simulaneously, because CANas uses IDE=0, but AP uses extended CAN messages.

Please, refer to protocol documentation for more details.


CANopen

This feature provides support for CANopen protocol.

For physical layer, this protocol uses the same CAN bus as AP system (not virtual port), i.e. both system bus and CANopen can operate simulaneously, because CANopen uses IDE=0, but AP uses extended CAN messages.

The current implementation supports PDO only.


This is higher-level communication protocol, used to operate multiple vehicles with one or many ground control units. It is usually used on mhx nodes, and works together with Radio module and ATS

The protocol is connected to available WAN interface (radio, USB) and wraps all telemetry and uplink data to address the vehicles this data belongs to.

When the vehicle is 'selected', the GCU is requesting the downlink stream (once a second), and when the driver accepts these requests (SQUAWK matches), it sends the data stream, otherwise, when there's no requests for stream, the driver sends just transponder data (XPDR), with only basic information about the vehicle.

The XPDR data structure can be found here /usr/share/gcu/gcu-sdk/inc/node.h and contains the following parameters:

The GCU may change the SQUAWK dynamically, if it detects inconsistency (same numbers on other vehicles). This procedure is automatic and reported in the console.

The following parameters tune the behavior of this feature:


Encoder interface

Encoder

This interface reads data from different encoders. Encoder measures position, calculates speed (derivative) and provides filtered values to Servo Regulator. The output position value is normalized from -1 to +1.

The supported encoder types include:

The following parameters are available:


GPS Receiver

This feature provides U-Blox GNSS module management. The driver provides data for autopilot's AHRS system, reports some statistics (used/visible satellites), and synchronizes the time with GPS Time.

The node supports the command Report satellites info which outputs current radio channels signal levels. It also measures noise, when the option itfm is on.


Gimbal

This subsystem controls generic gimbal and performs its gyro-stabilization.

All controls are sent throgh CANopen to actuators (servo), it does not use other methods, like Ports to control actuators.

As controls input, gimbal accepts the following mandala variables (depending on current configuration):

The available settings


Intertial Measurement Unit

IMU

This feature provides data from inertial sensors, which then is used by autopilot's AHRS sub-system.

The module usually includes the folowing sensors:

One or several IMU features can present in one system. The AHRS will automatically fuse all data. Important requirement is that all IMUs have to be properly aligned to each other with align, flip and hdg setting.

The common practice is to use IMU of GPS node to provide magnetometer, since it could be located in a better place (less hard-iron) than NAV.

Inertial Sensors

When device boots-up (on power on or reset), the IMU is initialized, and the orientation is detected, assuming that the device is in level position, parallel to the ground. The detected orientation is reported to the console, f.ex. IMU: bottom (that means the bottom side of the device is looking down).

All yaw headings of all IMU's in the system should always be aligned physically between each other.

For safe operation it is strongly recommended to adjust flip and hdg settings, after device installation to the vehicle. Moreover, if the IMU used to supply only the magnetometer to AHRS, it still have to be properly aligned (using these settings) with the device used for inertial sensors.

The good practice is to check gyro bias to monitor system health after some vehicle changes or modifications, with the command Estimate gyro bias. The numbers should be close to zero on working temperatures.

Inertial sensors tuning:

Magnetometer

Magnetometer uses alignment, configured in IMU settings. Although, it has some specific parameters:

The sensor outputs normalized vector of magnetic field strength. The values are within rane -1..+1. The proper hard-iron calibration is required, and can be performed with the GCU software plugin.

Note

The magnetometer calibration must be performed after the alignment of the sensor. When the alignment parameters (flip, hdg) are changed - the hard-iron calibration must be performed again.

Before the calibration, the settings bias and scale should be set to default values: bias=(0,0,0), scale=(1,1,1).


MHX Node functions

mhx/function

This node could be configured for different functionality.


OneWire

This feature have ability to collect data from 1-wire sensors (temperature).

Once enabled cnt>0, the device enumerates 1-wire bus and detects connected sensors. If the number of recognized sensors on boot-up sequence is not equal to cnt - the device reports error and stops further processing.

Each temperature sensor could be binded to mandala variable in bind setting.

Some sensors provide CRC functionality to protect data from noise errors, this could be enabled in crc property.


Pitot heater

Heater

This feature provides control of pitot probe heating.


Ports Multiplexer

mux

The physical signals of other subsystems of the node can be ramapped to any available multiplexed ports, i.e. the physical output pins on the PCB can be internally remapped to any available driver, interface or internal signal.


Ports and controls

Ports

This feature connects logical variables with physical signals on the vehicle.

Ports/controls

The control channels (outputs to servo drives) can be mixed and configured in this setting. Output channels are labelled as CHx and one or many different Mandala variables can be mixed together to one channel.

If several variables (controls) are binded to the same channel, the output of channel is the sum of all outputs.

The following fields are available for controls mixing:

Each channel can output value from -100% to +100%. Thus, the ouput from mixer (see above) is multiplied by 100, to convert units to percents. The channel output can be limited and adjusted, independent of mixers. This is useful to setup servo mechanical limits or mechanical zero position.

For example:

The output channels can be controlled through VirtualMachine.

Ports/gpio

Digital inputs-outputs can be configured in this setting. Each physical line can be binded to Mandala variable and act as digital input or output.

The following fields are available:

Ports/mixer

This is a hardcoded mixer option, f.ex. for quad-copters.

Ports/freq

This setting tunes the output frequency for PWM modulator, used to generate signals for servos, i.e. outputs from controls.


Radio

The driver configures the radio module Microhard mhx P400/P900/n920x 900MHz spread spectrum. The common PMP (Point-To-Multipoint) network consist of one or mode modems, configured as a Slave, and the only one modem, configured as Master.

The whole PMP network is isolated from another PMP network by the unique network ID. I.e., there could be two or more PMP networks with their dedicated Master modems. Although, the bandwidth is shared between all networks.

The following parameters are configuring the network topology:


Sensors redundancy

Sensors

This section configures the fusion priorities of different sensors of the same kind, installed in one node. For example, if the board have two different gyro sensors, you may setup which one to use as primary source for local data.

There is still another redundancy level present, related to data sources from different physical nodes, specified in prio setting of the corresponding sensor configuration group.

After changing the sensor source, it is usually required to adjust corresponding tuning values (bias, hard-iron calibration, etc.)


Serial Ports

This feature provides physical serial ports mapping to Virtual Comm Ports (VCP). All VCP ports are accessible by Serial Protocols through unique portID number.

The physical layer tunings are listed below:

Some implementations may contain additional settings for PHY configuration.

For programming reference of used ESC protocol, refer to GCU SDK file:

/usr/share/gcu/gcu-sdk/inc/escaped.h


Serial Protocols

Protocols

This feature provides drivers for different serial data protocols. Any serial protocol can be linked to Virtual Communication Port through portID setting.

The common options for the protocol are:

Some protocols and settings are described in details below.

NMEA

This protocol is able to receive and send ASCII text messages of the following format:

$variable name,value*CRC

All lines are delimited with either \n or \r or \n\r or space characters.

Examples of the NMEA line output:

The protocol is transmitting only those lines (variables) that are selected using the request enable.

Supported requests:

Examples of valid NMEA requests:

MODBUS

This protocol is for requesting and receiving of MODBUS packets. It is used for reading of different sensors via RS485 bus.

The following parameters of MODBUS protocol are configurable:

VISCA

This protocol is output only and controls some options of Sony-FCB cameras via UART.

The following features are supported:

DST

This protocol controls DST Gimbals (OTUS).

The following features are supported:

Supported modes, controlled through *cam_mode* variable:

The following settings are available for the protocol:

VOLZ

This protocol is output only and controls Volz servos via RS485.

The protocol sends a packet with commanded servo position every 5 ms. All servos must be pre-configured and channels should be assigned. The protocol will continuously update all servos with values from Ports mixer and the total number of servos is set in cnt setting. It is recommended to assign channels in sequence, without gaps, to minimize traffic.

HBC

This protocol controls MGM-COMPRO industrial BLDC controllers (via CAN). Up to four motors could be controlled. Parking feature is also provided. The connected controllers are auto detected and monitored.

The following settings are available:

SBUS

This protocol controls Futaba SBUS servos (via RS485). The servos must be pre-configured and channels should be assigned. The protocol will update servo positions, taken from Ports mixer output channels. The SBUS packet is sent every 12 ms.

XPDR

This protocol controls Microair T2000UAV transponders. The transponder is auto detected and monitored, turned on and off (power controlled) according to *power_xpdr* mandala value. The absolute baromeric altitude is updated form *altps* variable. The SQUAWK must be provided, according to the regulations, in squawk setiing.

JETCAT

This protocol controls JetCat turbojet engine. The engine is initialized and monitored, the start procedure is initiated by *sw_starter* variable and the rpm is controlled from *ctr_throttle*. The current status is reported in the console.

The following parameters are monitored:

To start the turbine:

To shutdown the turbine, turn *power_ignition* off.

This protocol reads data encoded in MAVLINK packets.

The following messages are supported:


Servo regulator

servo

bldc

The regulator parameters could be adjusted to tune servo motor behavuir. This driver recieves encoder postion and speed from Encoder interface, commanded position or speed from Ports/controls module, and calculates required motor power control value.

Available generic servo parameters:

Regulator parameters

servo/Regulator

bldc/Regulator

servo/Safety

The following parameters are used to shut down the motor power in some situations.

Servo BLDC drive

bldc/Regulator/FOC

bldc

The driver is able to control Brushless motors with FOC algorithm.

BLDC options (FOC):


Virtual Machine

This feature provides scripting engine, capable of execution of user programs or protocols on node MCU in user space.

More information can be found here.