Required Hardware

- A Jetson TX (either TX1 or TX2).

- If the wireless network settings aren't done yet, the development board of the TX and things to connect to it: power cable, HDMI cable, ethernet cable, wifi antennas, screen, keyboard. You might want to use a mouse, in which case you also need a mouse and a USB hub.

- A computer connected to the same network you plan to connect the TX.

The steps we have to do are :

- Add our repository containing resources.

- Configure the network settings and change the password (if not done already).

- Install the required packages.

- Install and build our workspace.

Clone Repositories

We have a repository containing different files which we use during the process of setting up the Spiri. Clone it before we begin, and switch to the _pleiades_ branch :


mkdir ~/installations

cd ~/installations

git clone http://git.mistlab.ca/bramtoula/spiri-resources.git

cd spiri-resources

git checkout pleiades


Configure the Network

If you did not set the network settings already for the drone to connect to your network through wifi, here is how we do it:

Connect the drone on the development board to a screen with the HDMI cable, to ethernet, connect the wifi antennas and plug a keyboard (and possibly mouse) in. Once you have it all, you can reboot the TX.

To connect to a network through the wifi interface, we use wpa supplicant, and set the IP to be static. In our example, we assume that the IP addresses your network gives are `192.168.12.XX`, but you might have to adapt that to your network if it uses different addresses.

First, open a terminal (Ctrl + Alt + t) and open the interfaces file to setup the IP to be static :

`sudo nano /etc/network/interfaces`

You should have the following inside, replacing the IP in `address` with the one you want for your Spiri :


# interfaces(5) file used by ifup(8) and ifdown(8)

# Include files from /etc/network/interfaces.d:

source-directory /etc/network/interfaces.d

# The loopback network interface

auto lo

iface lo inet loopback

auto wlan0

iface wlan0 inet static

address 192.168.12.<the number you chose for your drone’s IP>



wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf


Second, open the wpa supplicant conf file to define which networks to connect to :

`sudo nano /etc/wpa_supplicant/wpa_supplicant.conf`

In this file, you can set up one or more networks you want to connect to. If the network is open and has no password, you should use the configuration like the first network below. If it does require a password, use the second network below. You can add as many networks as you want, defining different priorities. If a robot sees different available networks it will connect to the one with highest priority.

If you are using some kind of filtering on your router (MAC filtering for example), don't forget to allow your Spiri!
















Once you have these files changed, reboot the drone and make sure it connects to the network.

You can check your drone gets the expected IP using `ifconfig`.

You can verify that it is connected to the network by trying to ping the router from the TX (you might have to adapt the address) :


If you get no response then there is an issue somewhere.

The next test you should make is to try to SSH to the TX. From another computer on the same network use :

`ssh nvidia@192.168.12.XX`

replacing XX by the IP of your TX. If you didn’t change the password yet, it should still be `nvidia`.

One helpful thing you can do is add the drone to your ssh config file to easily connect to it later. On your computer, run :

`sudo nano ~/.ssh/config`

And add the following at the end, replacing <spiri-name> and <spiri-IP> by the actual name and static IP of your Spiri :


Host <spiri-name>

User nvidia

Hostname 192.168.12.<spiri-IP>


Now you'll be able to run the following command on your computer to access the drone :

`ssh <spiri-name>`

It is important that this works before going forward since it will be our only way to access the TX once it is inserted in the drone.

While you are connected on the TX through a keyboard, it would be a good idea to change the password if not done already.

Use the commands `sudo passwd` and `passwd`.

Install Buzz

We need to install Buzz :


cd ~/installations

git clone https://github.com/MISTLab/Buzz.git

cd Buzz

mkdir build

cd build

cmake ../src


sudo make install

sudo ldconfig

cd ~


Now we should have everything needed for our code to work!

## Install and build our drones workspace

We can now download and build our workspace which contains the code we will run :


mkdir -p ~/ROS_DRONES_WS/src

cd ~/ROS_DRONES_WS/src

git clone https://github.com/MISTLab/ROSBuzz.git rosbuzz

git clone https://github.com/MISTLab/XbeeMav.git xbeemav


We provide files to build the workspace, and a launch file, which are in the `spiri-resources` repo you downloaded earlier. To build :



cp ~/installations/spiri-resources/build_spiri.sh ~/installations/spiri-resources/build.sh ~/installations/spiri-resources/spiri.launch .



Make sure you have the following files at the end of the bashrc file (`nano ~/.bashrc`) :


source /opt/ros/kinetic/setup.bash

source ~/ROS_DRONES_WS/devel/setup.bash

source ~/ROS_DRONES_WS/src/rosbuzz/misc/cmdlinectr.sh


You can now reboot the TX. Once it is rebooted, make sure you are able to launch the spiri node, even though it might still have some errors when running at this point :

`roslaunch ~/ROS_DRONES_WS/spiri.launch`.

You should also run the following command to add the right rules for using the Xbees :

`sudo sh -c 'echo "KERNEL==\"ttyUSB*\", MODE=\"0666\"" > /etc/udev/rules.d/55-usbserial.rules'`

If you got here, you're all set to assemble your Spiri!

# Assembling the Spiris (if not done already)

For this part, you'll need :

- A TX computer with the software described previously installed.

- A Spiri frame and the two blue parts forming the outer shell.

- An Elroy companion board.

- Wifi antennas (the flat ones).

- An Xbee module with the shield and antenna, as well as a short cable with mini USB to male USB A connectors, and a cable which connects on the P10 pins of the Elroy and has a female USB A connector on the other side.

- A radio receiver paired with the controller you plan to use, and a JST-GH to 5 pins cable.

For this part, you should have a look at the already assembled Spiris to see where things go.

The steps are basically :

- Remove the TX board from the development board, and remove the heat sink from it.

- Connect the TX board to the Elroy companion board.

- Remove the blue shell parts of the Spiri if not done already, and remove the « hat » of the frame which should be held by 4 screws.

- Insert the TX+Elroy inside the Spiri frame designated area and use the screws to fix the modules there.

- Use double sided tape to attach the two flat wifi antennas under the frame, and connect them to the TX.

- Connect to the Elroy all the cables from different modules which should already be installed on the frame.

- Connect the appropriate cable to the P10 pins of the Elroy. Connect the short mini USB to USB A cable to the female USB A connector of the first cable. Connect the mini USB to the Xbee shield, on which you have the Xbee module.

- Install the radio receiver on the frame, and tighten it (probably using a zip tie). Connect it using the JST-GH to 5 pins cable.

- Put back the « hat » and close the shell.

You should now have an assembled Spiri!

# Xbee setup

Now that you have an assembled Spiri, you can verify that the Xbee module works.

When powering on the drone, after a few seconds you should see a red light on the Xbee shield. If you don’t, there might be some compatibility issues between the TX and the Elroy version you have (see the part about flashing the TX earlier).

## Add the profile

To set the right profile on the Xbee, you should install XCTU on your computer (https://www.digi.com/products/xbee-rf-solutions/xctu-software/xctu#productsupport-utilities).

Using this software, you can load the profile from one of the files provided in the spiri-resources repo (http://git.mistlab.ca/bramtoula/spiri-resources.git) in the `xbees`folder.

We have one file for the Xbee PRO model « profile_8074.xpro », and one for the Xbee SX « xbee sx.xpro ».

## Verifying the database and take off heights

Now we have to check that the Xbee is in our database file. To do so, right down the serial number of the Xbee (written on it or found in XCTU).

Then, on the Spiri, check the database.xml file :

`nano ~/ROS_DRONES_WS/src/xbeemav/Resources/database.xml`

If you don’t see the serial number of your Xbee here, you should add it with a new ID number.

If your Xbee was already in the database, you can check the takeoff height associated with it in the following file :

`nano ~/ROS_DRONES_WS/src/rosbuzz/buzz_scripts/include/utils/takeoff_heights.bzz`

If your Xbee was not there and you had to add it, you should add a line in that file setting a takeoff height for the ID you added.

If you had to add your Xbee to the files, it would be a good idea to push the changes you made to the repo.

# Setting the controller and the flight controller

For this part, you should have :

- An assembled Spiri which connects to a network you have access to.

- A battery.

- A computer connected to the same network as the Spiri.

- The controller paired to the receiver installed on the Spiri.

## Settings on the radio controller (MISTLab radio controller - FS-i6X)

First, make sure you have the right settings on the radio controller.

We are currently using a FS-i6X. On these, we access the settings by long pressing the Ok button. When you want to save a change in setting, you have to long press the Cancel button.

You should compare your new controller and make sure it has the same settings as the other ones.

The changes we have from the default settings should be :

- In System -> RX setup -> Output mode. You should have Output : PPM and Serial : S .BUS.

- In System -> Aux switches. You should have all switches On.

- In Setup -> Aux. channels. You should have Channel 5 : Source SwC, Channel 6 : Source VrB, Channel 7 : SwA, Channel 8 : SwB.

## Accessing the flight controller

To access and monitor the flight controller, we use the QGroundControl software, which you should install on your computer (https://docs.qgroundcontrol.com/en/getting_started/download_and_install.html).

Once you have it installed, you have two ways to connect to the flight controller.

  1. You can connect a USB A to micro USB cable from your computer to the port on the flight controller itself. In that case you don't need to power the drone with a battery.
  2. You can connect to it through wifi, in which case you need a battery to turn the drone on. Here is how:

First, ssh to the TX on the drone:

`ssh nvidia@192.168.12.XX`

Then run this command, changing XX.XX.XX.XX by your computer's IP address :

`sudo mavproxy.py --master=/dev/ttyTHS2 --baudrate 57600 --aircraft Spiri_Name --out=xxx.xxx.xxx.xxx:14550`

You should then have QGroundControl on your computer receive information from the flight controller.

This interface is very helpful if you want to understand why your drone is not behaving as expected (either thanks to warning messages, or to get the logs which can later be analyzed here : https://logs.px4.io/upload).

## Setting parameters on the flight controller

If this is the first time the flight controller is used, you should connect to the QGroundControl interface with one of the ways described before, and do the following things :

- If the top right says ArduPilot instead of PX4, you should flash the firmware to use PX4.

- In Airframe you should make sure you have a quadcopter.

- You should calibrate all the sensors.

- You should calibrate the radio controller.

- You should calibrate the ESCs (in the power menu). This requires to connect through a cable, and having a battery.

The sensor calibration should be performed often, and every time you use the drone in a new environment.

You also have access to all the other parameters on the interface, but we have a script to set all the ones we change automatically.

You need to add a launch file in the mavros package to have one ready for the Spiris.

Let's copy the launch file from that folder to the mavros launch files :


roscd mavros

cd launch

sudo cp ~/installations/spiri-resources/px4_spiri.launch .


You can now launch this file :

`roslaunch mavros px4_spiri.launch`

You should see messages indicating that parameters are being transferred from the flight controller to the computer. Once all the parameters have been transferred, we can run our script to set all the parameters properly.

We have a script which sets all basic flight controller settings in the `spiri-resources` repository. Some lines are commented and define the settings appropriate to use our FS-i6X radio controllers. If you are using those controllers, you can uncomment the lines before running the script. Otherwise, you can adjust the parameters to your radio controllers, or set the appropriate settings throught QGroundControl.

To run the script, make sure you still have the mavros node running, and run :


cd ~/installations/spiri-resources/



When the script is done running, the flight controller should reboot and make some initialization sounds.

If that went well, you can stop the mavros node, and your Spiri should have all the right parameters.

# Radio controller usage

Here you'll find the current setup of the MISTLab radio controller.


# Running the rosbuzz node manually

For this part, you should have :

- An assembled and calibrated Spiri connected to a network.

- A computer connected to the same network as the Spiri.

- The drones workspace built, installed, and sourced.

- An Xbee registered in the database with an appropriate take off height.

To run the rosbuzz node simply use :

`roslaunch ~/ROS_DRONES_WS/spiri.launch`.

After finding GPS and recognizing the Xbee module, you should see logs telling you that the state is TURNEDOFF.

From this state, your drone will be able to receive commands from other drones and perform tasks.

One test you can easily make is to open another terminal on the Spiri, switch the control to offboard control with the radio controller, and use the following commands to takeoff and land, while the node is running :


takeoff mavros

land mavros


# Running the rosbuzz node on boot (recommended)

You might not want to have to connect to each drone to run the rosbuzz node yourself every time. In that case, it is a good idea to make a service which will run the node every time the drone boots.

For this part, you should have :

- An assembled and calibrated Spiri connected to a network.

- A computer connected to the same network as the Spiri.

- The drones workspace built, installed, and sourced.

- An Xbee registered in the database with an appropriate take off height.

To run the node on boot we have a script which waits 40 seconds, reboots the fight controller, then waits 10 seconds, and runs the node.

It is necessary to wait and reboot the flight controller due to some issues we experienced when the flight controller was initialized with the Spiri upside down (while inserting the battery). The flight controller should actually be initialized with the Spiri upwards and on the ground.

Copy the appropriate script in the init.d folder and make it executable:


sudo cp ~/installations/spiri-resources/bootscript/launch_rosbuzz.sh /etc/init.d

sudo chmod +x /etc/init.d/launch_rosbuzz.sh


In the script, you should modify the IP address to the one on the Spiri you are using :

`sudo nano /etc/init.d/launch_rosbuzz.sh`

and change the addresses in these two lines :



export ROS_IP=


Then add the service to the Default runlevels :


cd /etc/init.d

sudo update-rc.d launch_rosbuzz.sh defaults


Create the folder where the logs will be stored :


mkdir /home/nvidia/init_logs


Now when you reboot you should have the service running.

You can monitor what is happening by checking the service status :

`sudo service launch_rosbuzz status`

The script also writes the logs of the rosbuzz node in `/home/nvidia/init_logs/spiri_node.log`

If you want to stop the service from running on boot, you can run

`sudo rm /etc/rc*/*launch_rosbuzz*`

You can also temporarily prevent it from working by using this :

`sudo chmod -x /etc/init.d/launch_rosbuzz.sh`

and put it back with :

`sudo chmod +x /etc/init.d/launch_rosbuzz.sh`

(Helpful : https://help.ubuntu.com/community/UbuntuBootupHowto)

# Controlling robots with the web interface

For this part, you should have :

- One or several assembled Spiris which can run the rosbuzz node, with the radio controllers.

- A computer to be the groundstation.

- A Xbee module registered in the database, with antenna, carrier board, and cable to connect to the computer.

- A computer or tablet to have the interface on (can be the same as the groundstation computer).

## Set up the groundstation

For the first use you need to set up the computer you will use as the groundstation.

We will also need the `spiri-resources`repo on the groundstation :


mkdir ~/installations

cd ~/installations

git clone http://git.mistlab.ca/bramtoula/spiri-resources.git

cd spiri-resources

git checkout pleiades


If you don't have ROS Kinetic on your groundstation computer yet, install it :


On the computer, also install Buzz :


cd ~

git clone https://github.com/MISTLab/Buzz.git

cd Buzz

mkdir build

cd build

cmake ../src


sudo make install

sudo ldconfig

cd ~


Install mavros things :


sudo apt-get install ros-kinetic-mavros*


Create the workspace and add the necessary packages :




git clone https://github.com/MISTLab/ROSBuzz.git rosbuzz

git clone https://github.com/MISTLab/XbeeMav.git xbeemav


We provide a script to build the workspace, which is in the `spiri-resources` repo you downloaded earlier. You might have to install a few things to get it to build properly. Run :



cp ~/installations/spiri-resources/build_groundstation.sh ~/installations/spiri-resources/build.sh .



Source necessary files :


echo "source ~/ROS_GROUNDSTATION_WS/devel/setup.bash" >> ~/.bashrc

echo "source ~/ROS_GROUNDSTATION_WS/src/rosbuzz/misc/cmdlinectr.sh" >> ~/.bashrc


**Set up the web server**

Inspired from Fractal by HTML5 UP html5up.net | @ajlkn. Demo video: https://youtu.be/oY1XP5C_D4Q

You need first to have a fully working ROS/Gazebo/Buzz environment. Since this will be used as a webpage server, you need to install apache2 and either redirect apache server to where you cloned this repository or copy these files under /var/www/html/.


sudo apt-get install apache2


You can also take the `webcontrol` folder from the `spiri-resources`repo to the groundstation workspace :


cp -r ~/installations/spiri-resources/webcontrol ~/ROS_GROUNDSTATION_WS


To redirect Apache2 DocumentRoot, edit the file `webcontrol/001-rosbuzz.conf` with the location of your `webcontrol` files and add it to your Apache2 system files: `/etc/apache2/sites-available/` and `/etc/apache2/sites-enabled/`. You may also need to edit `/etc/apache2/sites-available/default-ssl.conf` variable `DocumentRoot`.

To be able to edit scripts on the host, you need to enable webdav (https://www.techrepublic.com/article/how-to-enable-webdav-on-your-ubuntu-server/):


sudo a2enmod dav

sudo a2enmod dav_fs

sudo service apache2 restart

sudo mkdir -p /var/www/webdav

sudo htpasswd -c /var/www/webdav/passwd.dav USER

sudo chown root:www-data /var/www/webdav/passwd.dav

sudo chmod 640 /var/www/webdav/passwd.dav

sudo service apache2 restart


If not installed already, you will also need to install rosbridge:


sudo apt-get install ros-kinetic-rosbridge-server


We will later launch the rosbridge server in the groundstation launch file.

## Setting up the geofence

A global geofence is implemented to avoid any member of the fleet to fly away, but it has to be manually configured each time the field location changes. The geofence can be a convex polygon of any shape, with a minimum of three vertex (four are recommended). The GPS coordinates of the vertex must be entered in two files:

- ~/ROS_GROUNDSTATION_WS/src/rosbuzz/buzz_scripts/include/act/navigation.bzz (at the top)

- ~/ROS_GROUNDSTATION_WS/webcontrol/assets/js/rosbuzz.js (near the bottom)

Since the groundstation is not required to have a GPS sensor, its coordinates must also be entered manually, again in two files:

- ~/ROS_GROUNDSTATION_WS/src/rosbuzz/launch/groundstation.launch

- ~/ROS_GROUNDSTATION_WS/webcontrol/assets/js/rosbuzz.js

## Run the interface and control the drones

To run the web control interface, you can launch the groundstation node on the groundstation computer with the Xbee connected to it.

There are a few settings you can change in the groundstation launch file if you are running a simulation for example. You can get more information in the ROSBuzz readme or check the launch file here :

`sudo nano ~/ROS_GROUNDSTATION_WS/src/rosbuzz/launch/groundstation.launch`.

If you are running a real experiment on drones, you can simply use the following to launch the groundstation node :

`roslaunch rosbuzz groundstation.launch`

Once that node is running, you can open a browser and go to the IP address of your groundstation. You should have the webpage to control the drones appear.

You should see the drones running the rosbuzz node (in a TURNEDOFF state) show up on the map. Don't forget to switch them all to offboard control before trying anything.

Here are a few tips on using the interface :

- To switch from individual waypoint control to swarm deployment, use the boolean *WP* at the top of webcontrol/assets/js/rosbuzz.js

- If you make any changes in the rosbuzz.js script file, a hard reset may be required on your browser to get rid of the cache (ctr+shift+F5+R in Chrome)

- You can also use the webcontrol interface directly from a drone, without requiring a groundstation with an xbee, but your control is then limited to the wifi connection between the computer (or tablet) and the host drone. To do so, you have to install the webcontrol (instructions in the readme of https://git.mistlab.ca/dasto/drones/tree/sim/src/webcontrol) on the drone and change the value of variable *GS* to 0 in assets/js/rosbuzz.js

Have fun!

# **Troubleshooting**

**The Xbee doesn't get powered (no red light)**

First, make sure the TX and Elroy are receiving power. The power distribution board (the one with ESC+ written on it) has been known to fail. Also, the cable that goes on the P10 pins have failed a few times already.

If all the hardware seems fine, then you might have an issue with the compatibility of the Elroy board and TX you are using. See the part about using an older Elroy with a TX2 in the "Flashing the TX" part.

**I get errors concerning sensor values, and mavros parameters**

You might want to check the cables doing the serial connection between the flight controller and the TX. They can be fragile and get disconnected.

**My Xbee isn't recognized when running the rosbuzz node**

First, make sure the Xbee is connected well and powered.

Then, try pressing the reset button on the Xbee before launching the node.

If that doesn't help, make sure you have the right configuration on the Xbee.

**My drone sometimes moves weirdly**

Did you calibrate recently ?

**My drone doesn't reach the height it is supposed to**

Are you sure the flight controller was initialized with the drone on the ground and upwards ?

Tip : To reboot the flight controller while the mavros node is running, you can run :

`rosrun mavros mavcmd long 246 1 0.0 0.0 0.0 0.0 0.0 0.0`

To reboot it from the QGroundControl interface, go to the Parameters page, and click on tools in the top right part of the screen.

**My drone won't arm due to "Mag inconsistent" errors, even just after calibrating**

Some of the modules we use have a defective MAG0 sensor. Make sure that the parameter `CAL_MAG0_EN`is set to 0. If not, set it to 0 and reboot the flight controller.

If that wasn't the issue, you can try increase the value of the`COM_ARM_MAG`parameter.

**My drone won't arm when I don't have GPS**

This could be due to the Geofence setting we are using : return home.

It requires the drone to have a home position using GPS when arming. If you want to try arming indoors, you should change the `GF_ACTION` parameter to do a warning instead.