[FEATURE] Autopilot component

[podhrmic]

Summary

The autopilot component executes the mission and is the Flight controller for the platform. The autopilot runs as a Linux process (so called SITL target).

• it has a certain level of autonomy (waypoint following).
• it needs to be connected to flight simulator and simulated sensors (gyro, GPS, etc.)
• Source: https://github.com/ArduPilot/ardupilot/tree/Plane-4.5
• Version: Plane 4.5
• Target: Arduplane SITL
• for telemetry, we will use MAVLINK v2 message signing
• Mission Planner seems to support message signing, so we need to only manage a custom signing key

Acceptance Criteria

Develop an autopilot component, and integrate it with the rest of the OpenSUT. Specifically:

• Build the Ardupilot Plane SITL target (docs here)
  • locally and in the CI (consider caching the resulting binary)
• The ardupilot binary needs to be run separately from the supporting infrastructure, as we cannot use the provided SITL scripts
  • QGC runs either in a docker, or natively
  • the JSBSim simulation environment can run in a separate docker container or on the base platform, such that the senors data are provided
  • the appropriate TCP/UDP ports need to be exposed in the containers and connected together (use docker compose?)
• @spernsteiner a separate mavlink channel needs to be open for communication with the rest of the OpenSUT
  • this can be handled either by modifying the SITL target to have this secondary telemetry
  • or by routing the telemetry through a filter that can re-route / inject additional messages (maybe with MavProxy)
• demonstrate that a user can start the autopilot, QGC and upload a flight plan and execute the mission.

[podhrmic]

@spernsteiner you can use docker image ardupilot/ardupilot-dev-chibios-clang to build Ardupilot SITL plane or copter targets

[spernsteiner]

QGC runs either in a docker, or natively

Is it important that we test with QGroundControl specifically? MAVProxy has some basic ground station functionality built in, sufficient for uploading a flight plan and monitoring the vehicle's progress.

the JSBSim simulation environment can run in a separate docker container or on the base platform

Is it important that we use JSBSim instead of ArduPilot's built-in simulation model?

a separate mavlink channel needs to be open for communication with the rest of the OpenSUT

What sort of MAVLink clients to we expect to add in the future? Are there any particular types of telemetry they'll need to receive, or particular commands they may need to send to the autopilot component?

[podhrmic]

Is it important that we test with QGroundControl specifically? MAVProxy has some basic ground station functionality built in, sufficient for uploading a flight plan and monitoring the vehicle's progress.

MavProxy can be used as well, for our purposes there is not much difference.

Is it important that we use JSBSim instead of ArduPilot's built-in simulation model?

I think it is easier to use JSBSim to separate the simulator from the autopilot (see the diagram here), because we don't want the simulation model to be a part of the VM, but run in the base platform/external computer instead. JSBSim also integrates nicely with FlighGear for rendering (nice visuals), and we can swap the flight models later (more flexibility). So unless there is a significant blocker, I would prefer JSBSim over the built-in model.

What sort of MAVLink clients to we expect to add in the future? Are there any particular types of telemetry they'll need to receive, or particular commands they may need to send to the autopilot component?

Most likely it will be a system logger, recording some basic telemetry from the autopilot (takeoff, landing etc). Probably no autopilot commands at this point (but we should have the option to support all common messages)

[spernsteiner]

we don't want the simulation model to be a part of the VM, but run in the base platform/external computer instead

Having separate JSBSim would also make it easier to get engine temperature/pressure data (or any other measurements) to feed to MPS.

Currently I'm working on separating JSBSim from arduplane so they can be run on different (virtual) machines. arduplane's JSBSim integration is set up to spawn JSBSim as a child process of arduplane, and I think it may also be making some assumptions about having near-zero latency on the arduplane<->JSBSim connection due to connecting to localhost.

[spernsteiner]

With GaloisInc/verse-ardupilot#1 and #111, I've gotten arduplane in the guest VM to use a JSBSim instance on the base system as the simulator. This works (MAVProxy shows the plane flying the example mission as expected), but the simulation is very slow - I would estimate 5x-10x slowdown compared to native speed. The built-in --model plane simulator doesn't show this slowdown, so my guess is that it's due to the high overhead of VM I/O operations when sending data to or from the simulator. I'm planning to experiment with the simulation rate and network settings to see if I can get it to run at a more reasonable speed.

[spernsteiner]

After adjusting the simulation rate and some arduplane parameters, the autopilot and simulator now run at close to full speed in the VM setup. It seems like some of the autopilot parameters are tuned to the old update rate, so it has trouble controlling the plane in this configuration, but after tweaking NAVL1_PERIOD, it seems to fly and completes the example mission without going too far off course.

Next, I'm planning to write some scripts to run the complete autopilot/simulator VM setup.

[spernsteiner]

With #110 and #111 merged, I'm now working on scripts to make it easy to run the autopilot in the OpenSUT configuration. The first piece of this is #112; the rest is in progress on the 97-jsbsim-scripts branch. The vm_runner configs for running the autopilot are mostly done, but I still need to finish the scripts for running JSBSim and MAVProxy on the base system.

[podhrmic]

@podhrmic review the autopilot, depends on #96

[spernsteiner]

I checked off "Build the Ardupilot Plane SITL target" (done in #110) and "The ardupilot binary needs to be run separately from the supporting infrastructure" (done in #111 and #122).

I also tried connecting MAVProxy to the secondary port that Ardupilot opens by default (port 5762, instead of the default 5760). It showed all the same position and status information as when MAVProxy is connected to the main port, so it seems to be receiving telemetry. Based on these results, I checked off "a separate mavlink channel needs to be open for communication with the rest of the OpenSUT".

[podhrmic]

Great. I have the base image built, so hopefully I can check off the last box soon.