Finish MVP version of OES software

[mhoejgaard]

The software should be able to perform all required functions:

• Receive and monitor (compare) built-in and external GPS.
• Use a gsm module.
• Monitor connections (sniffing).
• Control the drone using dronekit.
• Take required action

[mhoejgaard]

The software is capable of performing the desired actions and have been tested partially in simulation and practice.

The current state is:

• Gps receiving and comparison

  1. The gpsHandler is capable of receiving nmea messages. The messages are stored and available through get_position()
  2. The gpsMonitor ensures a gps posititon is received from both the internal (only tested with simulation) and external gps (tested with real gps). If the timeout is to high, gps timeout or loss is signaled. Likewise, a signal is sent if the two gps positions differ too much.

• Gsm module

  1. A GsmTalker capable of transmitting json messages sent to a transmit_queue and periodic heartbeats are implemented and tested.
  2. A GsmReceiver capable of receiving json messages is implemented and tested. All messages except heartbeats are forwarded to a gsm_command_queue. The time of which a heartbeat is received is stored and accessible via get_heartbeat().
  3. The talker and receiver are fully tested while running on a laptop with connected to ground control gsm nodes through a hosted rabbitmq server at cloudamqp.com

• Connection monitoring

  1. A connection monitor is implemented and tested. It checks whether the last heartbeats on gsm, telemetry to the flight controller or the wired connection to the flight controller (using dronekit) are too old, and signals if they are. It is tested with flight controller simulation, and dummy function to return telemetry heartbeat and the real GsmReceiver
  2. Mavlink sniffing has been tested using pymavlink. This functionality is included in the ConnectionMonitor module but is not tested yet.
  • Control the drone using dronekit
    1. All functions necessary to control the drone are implemented. They have been tested in another script but are not yet tested here.

• Take required action

  1. The OnboardControl module reacts to signals from the monitors and the gsm_command_queue. It is capable of calling the drone control functions provided by dronekit.
  2. The OnboardControl has proved to react as expected upon signals emitted by the gps and connection monitoring modules.

We still need to test:

• Sniffing in practice
• That we can actually control the drone through simulation
• Everything in practice

[mhoejgaard]

The software is tested on the toradex without hardware connected. It still needs to be tested with gps, gsm, and sniffing.

[mhoejgaard]

Testing on Toradex: All modules seems to be working but very slow. Timeout increased heavily in pika blocking connections. Mode changed in dronekit seems to be delayed by 30-60 seconds.

[mhoejgaard]

Webinterface not tested due to persistent gsm error that could not be solved.

[mhoejgaard]

Webinterface tested working on Pi.

[mhoejgaard]

It has been decided to move the system to an RPi and use a regular 4G modem if allowed.

A 4G modem has been tested working very good with the RPi. The setup is documented in the wiki.

The dronekit part of the dronehandler has been translated to pymavlink, as dronekit kept reporting errors due to a seemingly hardcoded timeout.

[mhoejgaard]

The RPi has been set up with:

• 4G module (tested and working)
• udev rules for rx-sniffing and gps (the fc connection uses serial0 on the gpio)

The OES has been configured to read port settings from a config file named *config.cfg" placed in the OES/src/ directory.

OES.py has been tested in the lab and seems to work. It still needs to be tested outside with GPS fix on both GPS-modules. Should be done as first thing Monday morning.

[mhoejgaard]

The DroneHandler_pymavlink has been improved to maintain a state for the completion of the mission.

The mission is divided into the following states:

• Idle: Before the drone is armed.
• Takeoff: The drone is ascending.
• Enroute: The drone flies toward the destination.
• Landing: The drone is descending.
• Landed: The drone is disarmed and safe to approach.

The Onboard control has been modified to not perform any control in the idle and landed states.

[mhoejgaard]

The software has been tested on the drone and minor bugs like misspellings have been fixed. The test was successful and the drone reacted as expected.