Naubot

Naubots go out into the sea, power itself from the sun, and send you back photos from days- and months- long voayages. They can also monitor an aquatory, or may be catch fresh fish or automate kelp farms (depending on installed sensors and actuators).

The cognitive abilities of naubots (on a very primitive level, like stimulus-response) are kindly provided by Ardupilot and the main hardware components follow the RC modelling design principles.

The first naubot code name Zero, released as an open platform with all components available off the shelf and with detailed instractions on how to assemble and configure it provided below.

Zero has the following features:

• Raspberry Pi / Navio2

Hardware

Body of Naubot is the Flytec 2011-5 fishing bait boat, with most of the original electronics removed and replaced. So that the brain (or at least grey matter) now is Raspberry Pi 3 B+ single-board computer, and the heart is Navio 2 autopilot. There are some other parts in this physicality and the final (maybe be incomplete) BOM of tools and instruments looks like the following:

Power subsystem

I'm splitting it into its own section because it is a beast by itself. All we care on the model input is a stable whatever-we-choose-voltage. But it may come from different sources (solar and battery). For prototyping I just use an array of rechargable AA. NiMH chemistry is safe compared to LiPo and I already have a charger.

Note: The charger is not included but you may use any NiHM AA charger. It takes ages to recharge.

Communication

Well... Radio controllers are interesting. Let's start with the fact that they have transmitter and receiver while both parts are perfectly capable of both receiving and transmitting. Unlike the ones that come with off-the-shelf drones (including the Flytec I have), hobbiest RCs are highly configurable and flexible. And FrSky is considered to be THE most popular a powerful brand on the market. But with flexibility comes price, and the price is both $$$ and complexity.

My radio transmitter and receiver didn't bind at first and I had to upgrade firmware on both. There are two incompatible protocols for FrSky, ACCST and ACCESS and both come with some incompatible variations (EU and US, plus versions). As sales person said:

FrSky firmware version are such a mess now. ACCESS V1, ACCESS V2, EU LBT ACCST V1, EU LBT ACCST V2, FCC ACCST V1, FCC ACCST V2. You couldnt make a worse system if you tried :-)

Well, I've decided to go for the latest EU ACCESS, as it offers the best features and performance (and I'm in EU). However, some people don't like it since it is closed, unlike ACCST. The firmware upgrade process includes 4 stages:

1. Upgrade the RC transmitter firmware
2. Prepare an SD card for RC transmitter
3. Upgrade the RC transmitter radio firmware
4. Upgrade the RC receiver radio firmware

For the RC transmitter firmware upgrade I used the latest version of OpenTX Companion. Also you'll need to download SD card content from the same website. You'll also need firmware for transmitter and receiver radios. Once you've installed the tool unpack SD card content to a directory, unpack firmware files and place it into the SD card content FIRMWARE directory. Next:

1. Open the OpenTX Companion and configure it for your transmitter model
2. From the tool, click on Update and download the latest transmitter firmware
3. Insert an SD card into the transmitter and format it via transmitter menu
4. Power transmitter into boot mode and connect it to the computer via USB
5. Upgrade transmitter firmware via OpenTX companion (backup firmware first)
6. Copy SD card content (with radio firmwares) to the mounted transmitter SD card
7. Unmount transmitter drives, disconnect USB and reboot transmitter into normal mode
8. Upgrade transmitter radio firmware via transmitter menus (go to flash card, find the right firmware file, select Flash internal radio)
9. Connect transmitter to receiver via Smart Port
10. Upgrade receiver firmware via transmitter menus (go to flash card, find the right firmware file, select Flash receiver radio)

Note, that I cannot guarantee that I didn't miss a step here or provided 100% correct information. And if you do something wrong you risk to brick your transmitter, receiver or both.

Configuration

Describe configuration...

Tools

Drones are not a plug-and-play business. Maybe with some standard RC models it is, but not with the custom DIY projects where you define your specs yourself. You'll need to practice the dark arts of soldering, crimping wires, building frames. So you need tools.

Note: You also need flux. For some reason the tools package above doesn't include it (well, the tools are actually quite shit, but work for our project). Crimping tools are of a good quality.

Summary

The total of crazy £735. And I made few mistakes selecting components at first, so the actual spending is much higher. Well, choose your hobbies wisely!

Software

Ardupilot

I already mentioned that the main control logic of Naubot is implemented by Ardupilot. In future, I may add extra cognitive abilities by using Autoware, ROS based self-driving cars platform, that I'd like to adopt for nautical vehicles.

But today, it is just Ardupilot. Ardupilot may work on different hardware platforms (flight controllers) and since I spent a significant part of my life working with embedded Linux systems - I picked a Linux based one. Currently it is Raspberry Pi as the core processing module plus Navio 2 HAT with drone-specific hardware (such as GPS, accelerometer, pressure sensor, motor control, current and voltage sensor, etc). Navio 2 requires that you install a custom version of Linux, since Ardupilot will simply run as an exacutable file and will control Navio 2 hardware via Linux drivers, thanks to Real Time Linux subsystem.

With Ardupilot up and running, you can control your drone using a radio remote control (aka RC transmitter, see above) or by so-called MAVLink protocol on serial or network interface. The MAVlink was originally designed to configure drone parameters and send telemetry information to a ground station, but today it can also send control commands back to drone, so it is possible to control it from a computer.

To work with MAVlink protocol several software packages were developed. My favourite (due to support for multiple platforms) is QGroundControl. The main goal of a ground station is to display information about dron location, battery charge and other sensor's information. But now it is also possible to display information from camera (if exists) and define some simple tasks, such go to a certain location or specify a territory to patrol. Latest (beta?) of QGroundControl even has virtual joysticks, so you can control drone from a computer!

Radio calibration - initially it got stuck in the middle and I had to turn off virtual joystick in order for it to continue.

Linux

The Linux part is responsible for everything non-control-related. For example we would like to attacha a video camera to the boat and send the stream online over using a 4G modem. We may also use the same 4G connection to connect to a GCS instead of using WiFi. Most of the information and ideas here are derived from these two projects:

https://discuss.uavmatrix.com/d/38-navio-and-rpi2-create-the-ultimate-4g-drone https://habr.com/ru/post/414587/

Also the information about service creation is here:

https://www.raspberrypi.org/documentation/linux/usage/systemd.md

MAVProxy

With the default Ardupilot settings it connects to a GCS on port 14550. But we would prefer GCS to connect to the boat, or better - connect to a proxy server. MAVProxy is a python script that allows routing MAVLink messages in different ways and we will configure it to listen on TCP port 5762 and also connect to UDP port 15001 of naubot.com. On naubot.com we will also have MAVProxy listening for incoming connections from ports 15001 and 15002 so that it proxies messages between boat and GCS.

sudo apt-get install python3-dev python3-opencv python-wxgtk3.0 python3-pip python3-matplotlib python3-lxml python3-yaml
pip3 install pygame MAVProxy
echo "export PATH=$PATH:$HOME/.local/bin" >> ~/.bashrc

Create service to autostart MAVProxy to send logs to naubot.com.

Create file /etc/systemd/system/mavproxy.service (link), serves logs to local TCP port 5762 and naubot.com UDP port 15001.

Create home directory, enable and start service:

mkdir ~/mavproxy
sudo systemctl enable mavproxy
sudo systemctl start mavproxy

GStreamer

sudo apt-get install v4l-utils libgstreamer1.0-0 gstreamer1.0-plugins-base gstreamer1.0-plugins-\* gstreamer1.0-tools gstreamer1.0-libav libgstrtspserver-1.0-0 gstreamer1.0-rtsp

Check if your camera (assuming you have a USB one) is recognised correctly:

v4l2-ctl --list-devices
v4l2-ctl -d /dev/video0 --list-formats-ext
v4l2-ctl -d /dev/video0 --list-ctrls

Select formats your camera supports and stream it to your host:

# start first on host
gst-launch-1.0 -v udpsrc port=16001 reuse=true caps="application/x-rtp-stream,encoding-name=H264,payload=96" ! queue ! rtpstreamdepay ! rtph264depay ! queue ! avdec_h264 ! queue ! autovideosink sync=false

# start second on rpi
gst-launch-1.0 -v v4l2src device=/dev/video0 ! capsfilter caps=video/x-h264,width=640,height=360 ! queue ! h264parse ! rtph264pay config-interval=1 pt=96 ! rtpstreampay ! queue ! rndbuffersize max=65000 ! udpsink host=192.168.15.130 port=16001

To serve video streams from Raspberry Pi we'll use the rtsp-simple-server.

rtsp-simple-server is written in Go and Golang on RPi was a bit old at the time of writing. You'll need a new version of Golang for it, the installation recipe can be found at https://www.e-tinkers.com/2019/06/better-way-to-install-golang-go-on-raspberry-pi/

Create file ~/go_installer.sh (link).

chmod +x ./go_installer.sh
./go_installer.sh

Edit ~/.profile and add path to Go:

PATH=$PATH:/usr/local/go/bin
GOPATH=$HOME/golang

Install the RTSP Simple Server:

git clone https://github.com/aler9/rtsp-simple-server.git
cd rtsp-simple-server
go build

Serve the stream:

./rtsp-simple-server
gst-launch-1.0 v4l2src device=/dev/video0 ! capsfilter caps=video/x-h264,width=640,height=360 ! h264parse ! rtspclientsink location=rtsp://localhost:8554/camera

Watch the stream:

gst-launch-1.0 -v rtspsrc location=rtsp://navio.local:8554/camera ! rtph264depay ! decodebin ! autovideosink

Create services to autostart RTSP server and gstreamer to serve video.

Create file /etc/systemd/system/gstreamer.service (link), serves video for simple-rtsp-server on port 8554.

Create file /etc/systemd/system/rtsp.service (link), serves video from gstreamer on port 8554.

Enable and start services:

sudo systemctl enable rtsp
sudo systemctl enable gstreamer
sudo systemctl start rtsp
sudo systemctl start gstreamer

Server

Unlike with a WiFi connection the boat on a 4G link will not have a permanent IP address. So we need a way to access the boat via some intermediary that knows the boat address because the boat tells it every time when it connects to the Internet.

MAVProxy

Install MAVProxy:

sudo apt install python3-pip
sudo pip3 install MAVProxy

Create file /etc/systemd/system/mavproxy.service (link), naubot should connect to TCP port 15001 and GCS to TCP port 15002 (make sure that these ports are open).

Create home directory, enable and start service:

mkdir ~/mavproxy
sudo systemctl enable mavproxy
sudo systemctl start mavproxy

RTSP Simple Server

Note - for the bandwidth utilisation reason, we should receive video stream from the boat only if there are clients connected.

Create file ~/go_installer.sh (link).

chmod +x ./go_installer.sh
./go_installer.sh

Edit ~/.profile and add path to Go:

PATH=$PATH:/usr/local/go/bin
GOPATH=$HOME/golang

Install the RTSP Simple Server:

git clone https://github.com/aler9/rtsp-simple-server.git
cd rtsp-simple-server
go build

Create file /etc/systemd/system/rtsp.service (link) and update file ~/rtsp-simple-server/rtsp-simple-server.yml (link), naubot should connect to TCP port 16001 to publish video and GCS to the same port to retreive it. Also UDP ports 16002 and 16003 should be available for RTP and RTCP.

sudo systemctl enable rtsp
sudo systemctl start rtsp