Aerial footage with a kite

Not exactly a rc model nor any kind of drone, but I experimented in my summer vacations with a very cheap platform to get aerial pictures. The thing you need for it, is just wind.

A kite has especially in windy conditions some benefits:

• Can stay in the air without external energy like battery
• Stays as long as the wind is blowing
• Very cheap and robust
• Do not need any license nor plate

But of course also some drawbacks:

• Can’t move around much
• Is not allowed to fly higher than 100 m (sometimes even less)
• Need enough wind, but not too much as well

So I made a proof of concept and used my small kite on the north coast to carry an action cam with it. Even this small kite did it easily. The kite itself was used as a kind of “air hook”. Then through a lug on the kite another cord can be used to pull the cam up into the air.

The cam itself was connected to a kind of fin which make sure that the cam is always looking into a definite direction.

This works pretty good and can be easily enhanced. For example there could be a kind of light gimbal to be able to change the view of the cam while in the air. Or kind of mechanism to automatically control the kite to handle better gust.

 

Advertisements

Reuse of a toy quadrocopter in a toy plane

Last year I got one of the nice tiny quadcopter Cheerson TINY CX-95S . After a lot of enjoyable flights it was time to test if this copter can handle a 2s lipo. After 2 more flights with a bit more power, one of the motors died. This was the opportunity to think about using it on a fixed wing plane, to be more precise, on a toy plane with just two differential motors to do all movements. No servos are on this old AirAce Betty plane. One big plus on this plane type is, it’s very robust and hard to destroy.
To replace the old controller also has some advantages

• 2.4GHz based connection instead of 27 MHz
• Smaller electronic
• Stabilisation is build in
• Fully programmable

Disassembling the quadcopter shows that it has four main parts, the flight controller, the receiver connected via part/serial, the cam and the video transmitter. Cam and video transmitter are connected via usual analoge video signal. Video transmitter and flight controller use the same battery connection which means, the video-cam combination can also be used independent from the flight control.

The flight controller itself is a F3 based one, running a Betaflight firmware. The first thing to find out was, how the board is named within the Betaflight configuration software to be able to flash it to the latest version. In the configuration software the board was detected as “SPEV”, but there was no board named like this to choose for flashing.

2018-04-17 @ 06:51:40 -- MultiWii API version: 1.31.0
2018-04-17 @ 06:51:40 -- Flight controller info, identifier: BTFL, version: 3.1.5
2018-04-17 @ 06:51:40 -- Running firmware released on: Feb 7 2017 22:31:13
2018-04-17 @ 06:51:40 -- Board: SPEV, version: 0
2018-04-17 @ 06:51:40 -- Unique device ID: 0x1c00364234571820343534

So a full text search within the open source firmware files showed, that this “SPEV” is only used in the target.h file within the “SPRACINGF3EVO” folder. The name of the folder is the name of the board within the configuration software and can be successful flashed. In case of some problems with the flashing there I found the 2 boot pads on the board which helped a lot in my case. Because sometimes you have to use these. If you connect both pads the board goes into DFU mode and you can flash it.

Theoretically it’s also possible to flash other compatible firmware like iNav, but for the first tests it was easier to stick to the Betaflight software. Even if the iNav software has some useful additional functionality like autonomous navigation.

Next step was to use a custom mixer and only use the roll part for two motors. So the commands for the command line looked like this:

mixer CUSTOM
mmix reset
mmix 0 1.000 -1.000 0.000 0.000
mmix 1 1.000 1.000 0.000 0.000
save

The parameters have the following meaning. First is the motor number, then throttle, roll, pitch and yaw.
For some reasons it’s not possible to choose other combinations than 0 and 1 for the motor number, even if you would prefer for example 0 and 3 because the position on the board nicer to have less cables crossing the whole board. You have always to start from 0 and go on with 1, 2 and 3 depending on how many motors you want to use.

Because the plane need a 2S Lipo I thought it might be better to cut of the connection between the two pads on the board labeled with S1 and instead connect the pads labeled with S2.

After a first test flight it was clear that the default PID settings for roll are way too high. The plane wobbled a lot, but stays in the air and was controllable.
After some more flights and adapting the PID values the flight behavior becomes better and better. Now I used for roll PID the values 8, 7 and 4 and the plane flows quite good.

So in the end it’s quite nice to see that it’s possible to use all the parts of a cheap quadcopter within another vehicle. As long as the other vehicle does not need much more power and use the same motor type (brushed) as well as do not need anything else like servos. Some type of boats and coax-helicopter are constructed like this for example.

Position tracking without GPS

In an GPS denied environment one option to track the own position is with a camera which is mounted to see the ground directly from above. With a quadcopter this could be archived with a gimbal.
Two other preconditions are that the ground has good visible structures and there is sufficient light.

With OpenCV there are different optical flow methods available. The first approach used
Lucas-Kanade to track the points in the picture. To detect the movement of the cam it
used just a median of max 100 points. But this approach did not work very well.

The second approach was to build with max 21 points some triangles. There are a lot of
advantages with this triangle approach.

• Check possible if the triangle has the same ratio on the sites
• Calculate the middle of the triangle to calculate the translation
• Calculate the rotation of the triangle
• Calculate the scale of the triangle

In the screencast you can see that it works quite well.

The video to track was recorded with the smartphone and the screencast was done on a laptop of course.

But as you can see on the video, not only the movement can be tracked also the orientation and the distance.
Of course the movement related to the ground has to calculated together with the distance and the rotation.

Because of accumulating errors this navigation is not as exact as with GPS, but dependingon the scenario it might be good enough.

MAVLink tunnel through MQTT

On the opensource project uasmqtt now it’s possible to ‘tunnel’ MAVLink packets. That means it’s not only to control the smartphone from the ground and get it’s data. Through the same message queue mechanism MAVLink packets can send and received.

To get a proof of concept the AircamQC app was extended to get a bluetooth connection to the Quanum Nova/CX-20 APM quadrocopter. Also a small utility was created to listen on a TCP socket and transfer these data to the MQTT broker (TCPmavlink2uasmqtt).

At the picture you can see the working example. The picture itself was taken through the AircamQC app and triggered by the AircamQC Viewer app.

MAVLink packets are different in it’s size and have a starting id (0xFE). The payload length up to 254 bytes is following direct after the starting id. There are also some other importand status bytes so that a packet size is calculated by 6 bytes header + payload + 2 bytes checksum.

The drawback on this approach is the performance. It’s really slow for some reason. A better approach is not to interpred the MAVLink packet stream but to create proper topic structure and json content.
Then the smartphone app can act like a ‘companion computer’ and talk with the copter through MAVLink with all necessary information at the right time, like the heardbeat. But to another aircraft or groundstation the smartphone can talk in it’s own MQTT ‘language’ which should not be too time critical.

The experiment set-up is shown in the following picture.

Experiences with a new platform

For further development on smartphone apps it’s helpful to use a copter with buildin position hold and open source flight control.

Quanum Nova/CX-20 is small, the same size as a DJI phantom, and includes APM flightcontrol. Flight time with a Samsung Galaxy S3 as payload was about 5-6 minutes.

An advantage of the Nova/CX-20 is, that a lot of parts of the phantom also fit into it. For example the props, the prop nuts, the battery and also the cam gear.

Some tips if you buy a Quanum Nova/CX-20.
If it’s a PNF (Plug and fly = without receiver), you should watch the Hobby King video for setup.
Before every flight check if the prop nuts are tight. Otherwise you may loose a prop while flying.

For communication with mavlink tools. The usb connector on the Nova works with a default of 115200 baud, but the serial connection on the flight control has a default of 57600 baud. You can use it by soldering 4 wires on it (telemetry tutorial).

If you want to connect a bluetooth module on it, you should set the speed on the bluetooth module properly.

Not every application is helpful to set the baud rate on the bluetooth module. Minicom works but on OS X and Linux, “screen” was not really helpful and also Arduino IDE was not working.

Open source project for unmanned aerial system on MQTT base

Introduce of a new open source project which uses MQTT with Json data format to communicate between devices. At the moment it contains the parts uavMap to display position and Android app to transfer theses information and also take pictures on demand.

https://github.com/mobile2power/uasmqtt

Why use Message Queue Telemetry Transport with Json data format?

With MQTT you have a broker. Every device can send data and listen to new data complete independently. Means that MQTT has some benefits:

• With Json data format it’s open and independend from programming language
• Easy for testing. No problem to write a Mock and connect it to the broker.
• It’s scalable. Means for example you can have a couple of UAV in the air and control it all with one application. Every UAV can also listen to other UAV to prevent collision.
• With SSL and login or other authentification it’s secured by design.
• There are some mechanisms if connection is broken and in case of a timeout.

But there are also some drawbacks

• TCP has more overhead than UDP. Performance is lower.
• Not possible to have a direct device to device communication. Single point of failure and again lower performance.

But usually these drawbacks are not that critical. Only if you want to transmit live video it might be better to use another technology.

About the applications

The first app for the Android Smartphone just collects sensor values for location (GPS, Pressure Sensor) and attitude (Gyros, Accelerator). It uses Eclipse Paho mqtt client to communicate with the broker and Gson to generate json data format for location, attitude and view angle of the cam.
The app also registers a listener for the broker to get the trigger for the cam. Every photo is stored locally on the Smartphone with Geo tagging. Additional a json file is stored with the additional information about attitude and pressure based altitude.

The second application is a processing app to show a map with the actual position and orientation of the Smartphone. The pressure based altitude is shown as a number and a rectangle displays the covered area by the camera.
On every taken picture the rectangle marker stays in the position to see, what is already covered. Used libraries are UnfoldingMap, Qatja and again Gson.

Configuration

A really simple approach is to connect the Smartphone via tethering to a laptop with uavMap and the MQTT broker on it. But the wlan range has a limit about 50-70 m without the use of directional antenna.

It’s better to have 2 mobile internet connections running and MQTT broker on an internet server. Then there is no range limitation except the accesss to the mobile internet.

Test of MQTT performance for device communication

As alternativ to the selfmade UDP based protocol to transfer video, position and all the other data from a smartphone, the TCP based MQTT has some advantages on the paper:

• Encrypted communication possible (SSL)
• Proven protocol. Early version started more than 10 years ago.
• Standard protocol which means there are a couple of implementations
• Similar approach to ROS (robot operating system)
• Free server/broker available

But to check if the performance is sufficient there has to be a test. For the test the HiveMQ is used local on the Mac and also the receiving program which is created with processing (lib qatja used for MQTT). On the other side a small android app is created which use eclipse paho library to transfer camera preview images (10 fps).

The performance is not bad and the implementation was easy to do with these nice libs.