23. Setting up a new Vehicles for the flight arena¶
23.1 Vehicle Specification¶
Starling can be made compatible with almost all vehicles both ground and aerial. In the majority of cases, a vehicle is valid if it has enough compute to run docker containers and connect to the network. The recommended minimum is a Raspberry Pi 4 with 2Gb RAM with WiFi connectivity. The compute should be sufficient such that all the containers can be run safely without saturating the CPU, Memory or Netowrk Bandwidth.
23.1.1 Aerial Vehicles¶
The current system is designed with a PX4/Ardupilot compatible flight control (such as a Pixhawk or PixRacer) running in tandem with a companion computer such as a Raspberry Pi.
The current risk assessment covers multi-vehicle flight for vehicles < 1kg maximum take off mass.
23.2 Adding a new vehicle to Starling¶
Note: You will need SSH access to the flight arena server.
23.2.1 Companion Computer Boot Image¶
We have created a custom image which contains the minimum general elements to be compatible with Starling. The image has been generated using the code in the starling-64-mod branch of UobFlightLab/pi-gen. We have released a precompiled image file which can be flashed onto a USB or SD-card and booted from using a tool such as the Raspberry Pi Imager
The image is based on Ubuntu 20.04 for ARM chips (Raspberry Pi), and has the following elements:
- Password-less sudo
- Automatic connectivity to the Flight Arena LAN
- k3s airgapped installation files placed into root with
- GPIO drivers installed
- To ensure connectivity with the pixhawk,
99-px4fmu.ruleshas been added to
/lib/udev/rules.dto ensure the pixhwak is connected via
Chronylibrary has been installed and that
/etc/chonry/chonry.confis configured to use the flight arena server at
192.168.10.80(see the BRL flight arena doc)
- The Docker Daemon registry mirrors has been set via
/etc/docker/daemon.jsonto use the flight arena server at
192.168.10.80:5000to ensure the drone can pull docker images from the internet. (see the BRL flight arena doc)
23.2.2 Vehicle Specific Setup¶
A vehicle ID number from 10 to 255 must be chosen. IDs below 10 are reserved. It must be checked that IDs do not clash with existing vehicles (i.e. the Coex Clover drones take ids 11 - 14).
If the vehicle is going to be used with PX4 or Ardupilot, the flight controller system id should be chaned to the vehicle ID. e.g. setting
MAV_SYS_ID in QGroundControl for Px4 based systems.
If the vehicle is going to be used with the Mavros Container, a
/etc/starling/vehicle.config file is required. An example is the following:
VEHICLE_FCU_URL=serial:///dev/px4fmu:115200 VEHICLE_FIRMWARE=px4 VEHICLE_MAVLINK_SYSID=23 VEHICLE_NAME=clover23
23.2.3 Adding vehicle as a node.¶
The vehicle can now be added as a node to the cluster.
- Ensure that the vehicle is only connected to the LAN either by WIFI or Ethernet.
- Identify the IP address of the vehicle by going to the DHCP server on
192.168.10.252, or other means
- SSH into the flying server and
Run the agent setup script
start_k3s_agent.sh. This will ssh into the vehicle and run the setup script with the keys held by the server. See this doc for more details.
./start_k3s_agent.sh <remote username> <remote ip address> <node name>
./start_k8_agent.sh ubuntu 192.168.0.110 clover1
Add the following tags to the node either through the edit functionality in the kubernetes dashboard (the pencil in the upper right corner) or manually through the command line. The tag keys must be fixed, but the values can be varied depending on application. These are required for automatic deployment of containers.
starling.dev/type: vehicle starling.dev/vehicle-class: rotary starling.dev/vehicle-type: clover
The vehicle should now be visible under
nodes on the Kubernetes dashboard.