Set Up a Simulation Environment with the Intel® Aero Compute Board Developer Guide

An overview of simulation with software in the loop (SITL)

Abstract

SITL allows for running the Intel® Aero Compute Board on a PC directly, without any special hardware. It takes advantage of the fact that the Intel Aero Compute Board is a portable autopilot that can run on a very wide variety of platforms. The PC is just another platform that the Intel Aero Compute Board applications can be built and run on.

Table of Contents

Introduction
Simulation with software-in-the-loop
Required Components
  Mavlink
Generating mavlink.h and other headers
PX4 Firmware
Installation of Components
  Installing MavLink
  Installing PX4 Firmware
Writing MAVLink Applications over UDP in Simulation
  Sending Data
Porting simulation to the Intel Aero Compute Board
Conclusion
References

Introduction

This document covers the requirements for the creation of MAVLink*-based applications developed in simulation as software-in-the-loop (SITL) for the Intel® Aero Compute Board as it communicates with the PX4* flight controller.

This document serves only as a guide for working with the Intel Aero Compute Board and does not cover every situation a developer might encounter. Further, it is assumed that Ubuntu* 16.04 LTS is the OS where host development of SITL simulation applications will take place.

This document also mentions websites where you can get further assistance in setting up and developing against your Intel Aero Compute Board as well as the Intel® Aero Flight Controller. A great resource for detailed information on various aspects of working with the hardware can be found at the Intel Aero Compute Board GitHub* Wiki.

An easy development model

While it’s impossible to cover all the various ways a developer can try to accomplish a task, what I do here is give an overview of how I have been successful in writing applications that target the Intel Aero Compute Board platform.

Develop on a Ubuntu* 16.04 machine

Given that the Intel Aero Compute Board is running Yocto* as its OS, there is no easy-to-use GUI. Since I like GUI-based operating systems using feature rich IDEs, I have a computer running Ubuntu 16.04, and I use the latest version of Eclipse* IDE, which at the time of this writing is Neon.

I do as much development and testing as I can on my local computer, and then migrate the source code onto the Intel Aero Compute Board, recompile, and run the app. But you can develop directly on the board if you want to.

Migrate to the Intel® Aero Compute Board

The Intel Aero Compute Board has built-in Wi-Fi*. I use the Wi-Fi for migrating any source code files onto the board itself. Migrating code and files is straightforward. Just hook up your board and let it boot up. Once this is complete, I like to run lfconfig to ensure that the Wi-Fi is working properly. This is verified by seeing wlan0 as one of the devices.

NOTE: If you don’t see wlan0 as one of the devices in the list returned from lfconfig, try some of the workarounds listed on the Intel Aero Compute Board GitHub.

After ensuring that the board’s Wi-Fi is up and running, you need to connect your local computer to that network. Look for a network connection that has the name “CR_AP-xxxxxxx” where “x” represents a random number or letter.

The password for the Wi-Fi connection is 1234567890. To change it, modify the wpa_passphrase in /etc/hostapd.conf

Now that a connection has been established, we can migrate the files to the Intel Aero Compute Board. I do this via a shell script. The following is an example script that I created for another project, but it also works here.

#!/bin/bash

#Remove “MyProject” from Aero. I just like a clean migrate.
ssh root@192.168.1.1 'rm -r /home/MyProject'

# Copy over the Aero project
scp -r MyProject root@192.168.1.1:/home

# Copy over the make script for making Aero
scp makeProject root@192.168.1.1:/home
  • The idea here is that I want to remove all files off the Intel Aero Compute Board and do a full migration every time.
  • I then use secure copy to copy all the files over, including the folder where the files reside from my local Ubuntu machine, and then copy the folder and files into the home folder on the compute board.
  • Then I re-migrate my make file, which resides in the home folder.

It’s nothing elaborate, but it functions effectively and prevents me from constantly typing the same thing over and over. Once the files have been copied, I simply run the make file for the project, and then run the project to verify everything is working.

Simulation with software-in-the-loop

Simulation allows for safe testing of experimental code and settings. SITL simulation runs the complete system on the host machine and simulates the autopilot.

There are conceptually two types of simulations:

  • Hardware in the loop (HITL) simulation replaces the plane and the environment with a simulator. The simulator has a high-fidelity aircraft dynamics model and environment model (wind, turbulence, and so on). The physical APM hardware is configured exactly as for flight and connects to your computer running the simulator, rather than the aircraft.
  • Software in the loop (SITL) simulation (additionally) virtualizes the autopilot hardware as well as the aircraft and the environment as in HITL. SITL is useful for rapid development and when physical hardware (autopilots and ground stations) are not available or not required.

The SITL simulator allows you to run a UAV without any hardware. It is a build of the autopilot code using an ordinary C++ compiler, giving you a native executable that allows you to test the behavior of the code without hardware.

It is recommended that initial development for the Intel Aero Compute Board applications begin with SITL.

SITL allows you to run the Intel Aero Compute Board on your PC directly, without any special hardware. It takes advantage of the fact that the Intel Aero Compute Board is a portable autopilot that can run on a wide variety of platforms. Your PC is just another platform that the Intel Aero Compute Board applications can be built and run on.

Required components

Mavlink

MAVLink or Micro Air Vehicle Link is a protocol for communicating with small unmanned aerial vehicles (UAV). It is designed as a header-only message marshaling library. Its primary use is for communication between a ground control station (GCS) and UAVs. It can also be used in the intercommunication of the subsystems of the vehicle. It can, for example, be used to transmit the orientation of the vehicle, its GPS location, and speed.

MAVLink is a lightweight, header-only message marshalling library for micro air vehicles. It can pack C-structs over serial channels or UDP with high efficiency and send these packets to the ground control station. In addition, within the context of the UAV, it can be looked at as an interprocess communication scheme for data sharing among various compute processes that exist between the PX4 flight-controller and the Intel Aero Compute Board.

The remainder of this document focuses on the usage mode subsystem on the UAV.

Generating mavlink.h and other headers

As noted earlier, MAVLink is a header-only library, and as such no prior compilation of a library is required before using it. The headers are programmatically generated by Python* scripts that parse and analyze a set of commands and messages defined in XML and agreed upon by the community. For the case of the Intel Aero Compute Board with PX4, the common.xml file contains the target representation.

For more information on the specifics of generating mavlink.h and all associated headers, go to the GitHub repository at https://github.com/mavlink/mavlink.

PX4 firmware

The PX4 flight stack is a complete autopilot solution for multicopter and fixed wing aircraft. It consists of several customizable software packages.

  • PX4 flight stack: A complete flight control solution for multicopters, planes, VTOL aircraft, or any ground robot.
  • PX4 middleware: A highly efficient, lightweight, and fast robotics communication toolkit.
  • QGroundControl: A modern, mobile, and desktop user interface to configure the system and build autonomous flight paths.

The scope of this document is focuses on the PX4 flight stack, specifically the firmware that executes in the flight controller that is the recipient of commands and messages issued by the Intel Aero Compute Board.

The PX4 firmware can be found at the GitHub repo at https://github.com/PX4/Firmware.

The PX4 firmware has flight modes that define the state of the UAV at any given time. The user transitions between flight modes via switches on the remote control or the ground control station, or in what is termed “offboard mode” where the position, velocity, or attitude reference/target/setpoint is provided by the companion computer—in our case, the Intel Aero Compute Board—connected to the flight controller using MAVLink.

Installation of components on a developer machine

Installing MavLink

The MAVLink source base and tools required to generate the C header files can be found in the GitHub repo at https://github.com/mavlink/mavlink.

To clone the repo locally, open a terminal and execute the following command:

git clone -–recursive -–progress https://github.com/mavlink/mavlink.git

The top-level Readme.md (the front page) explains the contents of the repository. In addition, it offers detailed instructions on the use of the Python tools included to generate the bindings for several files, including the C headers required for development in that language.

Finally, there is a link in the examples/Linux directory for a program that sends data to QGroundControl using the MAVLink protocol. For more on developing for QGroundControl, see the QGroundControl developer reference. Reviewing this example will give you an initial understanding of how the message-passing mechanism of MAVLink works.

Installing PX4 firmware

This document does not go into deep detail on PX4 technology. For more details about PX4, please see the PX4 User Guide and PX4 Developer Guide. The developer guide even has an Intel Aero Compute Board page dedicated to flashing the firmware on the Intel Aero Flight Controller, if needed.

Using the PX4 Firmware, unlike MAVLink, involves building libraries and executables from the repository.

First, a local clone of the repository is required. From a terminal window, issue the following commands:

git clone -–recursive -–progress https://github.com/PX4/Firmware.git

cd Firmware

git submodule_update -–init -–recursive

Next, build the binaries by compiling the source code. It is recommended you proceed to the simulation for the SITL scenario. While it is possible to move to the hardware directly at this point, this is outside the scope of this document.

After ensuring that the simulation prerequisites are installed on the system, just launch. The convenience make target will compile the POSIX host build and run the simulation.[1]

In a terminal window, run the command:

make posix_sitl_default jmavsim

The first time the command is issued, the make program will compile several libraries and executables which can take a bit of time to compile. Once built, subsequent issues of this command will skip over those build artifacts.

After issuing the command two things happen:

  1. A PX4 shell is presented to the user.
  2. A JMavSim simulator—complete with quadcopter—is launched.

In the PX4 shell you can issue commands such as:

pxh>  commander takeoff
pxh>  commander land

This will effect a lift off and landing sequence of the quadcopter in the simulator.

Writing MAVLink applications over UDP in simulation

Applications written with the MAVLink protocol presumes a bidirectional connection between the flight controller and a GCS. The GCS composes the list of MAVLink commands as packets of messages (with appropriate data payloads) that are relayed from it to the UAV’s flight controller, and the vehicle responds appropriately.

However, as mentioned earlier in the context of the Intel Aero Compute Board, MAVLink can serve as a form of interprocess communication between the Intel Aero Compute Board and the Intel Aero Flight Controller. Command lists and data that would normally come from a GCS are programmatically generated on the Intel Aero Compute Board and in turn relayed to the UAV’s flight controller. This capability enables a degree of autonomy for the UAV mission planning that other solutions do not provide.

On a real UAV the PX4 flight controller and the Intel Aero Compute Board would be connected serially, and it is through that connection that messages and commands would flow between them. For purposes of simulation, the serial connection is replaced by a UDP connection.

It is possible then to write standalone applications that you can start, shut down, change, and restart while the simulation environment with the drone is running.

In this mode, the most important aspect of the standalone application lies in its ability to send data and commands—in the form of messages—via a UDP port to the host’s simulation environment.

The following pseudo-code snippet shows this:

int main(int argc, char *argv[])
{
    if (is_drone_connected)
        return -1;

    while(true) {       // Incredible efficient mainloop
        recv_data(); // Merciless check for data :)
        send_data(); // Merciless send data :)
    }

    return 0;
}

The snippet demonstrates that the Intel Aero Compute Board has to constantly run, receive data (from flight controller, in this case a “heartbeat” message), and send data (in this context, the list of commands sent by Intel Aero Compute Board to flight controller.)

Sending data

Sending data using MAVLink on the Intel Aero Compute Board to the simulation requires the following steps:

  • Establish a connection to a port for UDP communication and ensure that the application remains connected for the life cycle of the simulation.
  • Establish the MAVLink message to be sent and identify the appropriate message enum (defined in the previously generated headers).
  • Identify the appropriate data structs and requirements to fill, for example, position, velocity, and orientation.
  • Fill the memory buffer associated with the data structs; ensure that the memory buffer is valid and does not overflow.
  • Execute a MAVLink mavlink_msg_to_send_buffer; this essentially does a copy of the data in the message to the buffer.
  • Send the buffer out through the previously established UDP address and port and ensure that all bytes are sent.

To demonstrate these steps, the following pseudocode could be applied:

#include <arpa/inet.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/socket.h>
#include <unistd.h>

#include <common/mavlink.h>

#define BUF_SIZE 2048
int sock = 0;      // Socket file descriptor
socklen_t fromlen; // Just to make 'recvfrom' happy
/**
 * @brief Output connection parameters.
 *
 * Similar to input link, but we need to specify the port where the drone is waiting for packets
 * (14556). We will use the same socket to send the packets.
 */
struct sockaddr_in output_link;

send_data(void) {

    mavlink_message_t msg;
    static uint8_t output_buffer[BUF_SIZE];
. . .
// execute logic to determine which MAVLink message to send
. . . 
// Encode the MAVLink message and send it through our connection
    memset(output_buffer, 0, sizeof(output_buffer));
    mavlink_msg_set_mode_encode(10, 0, &msg, &mode);
    len = mavlink_msg_to_send_buffer(output_buffer, &msg);
    bytes_sent = sendto(sock, output_buffer, (size_t)len, 0,
                        (struct sockaddr*)&output_link, sizeof(output_link));
}

The above pseudocode relies on standard Unix* calls as well as MAVLink helper functions.

Porting simulation to the Intel Aero Compute Board

Once the standalone MAVLink application has been developed and tested to satisfaction within the simulation environment it is then ready to port to the Intel Aero Compute Board.

Familiarization with the various dependencies and steps required for building an application on the Intel Aero Compute Board is recommended. They are as follows:

Note that the above list presumes development of the application as a new start.

However, it is possible to build the standalone application for simulation on your host PC and then transfer the resulting executable to the Intel Aero Compute Board without any restrictions.

After building the standalone application you can execute a SCP (SSH copy) command and transfer the binary from the host PC to the Intel Aero Compute Board. Make check that the copied binary has root execution privileges as follows:

sudo chmod +x <your binary name>

Conclusion

Developing for a UAV with the Intel Aero Compute Board can be a complex process. This complexity can be decreased by relying on the MAVLink communication protocol and simulation with SITL to quickly test and iterate on the standalone application that will drive the autonomy of the UAV.

This document shows you one way that simulation with SITL can be used for developing Intel Aero Compute Board standalone applications using the following guidelines:

  1. Where to obtain the MAVLink protocol repository
  2. Where to obtain a reference PX4 firmware and simulation environment
  3. How to write a simple application in SITL
  4. Provide guidance on porting the application to the Intel Aero Compute Board

This document is not an exhaustive resource for information on the development of MAVLink and simulation with SITL. As such the reader is encouraged to look through the references provided herein and in subsequent articles in this series for additional guidance.

References

Official reference C / C++ library for the v2 protocol: https://github.com/mavlink/c_library_v2

1. http://dev.px4.io/simulation-sitl.html

Para obter informações mais completas sobre otimizações do compilador, consulte nosso aviso de otimização.