- Project name: 3DR solo drone support and behavior
- Author: Diego Jiménez Bravo
- Academic year: 2016 - 2017
- Degree: Degree in Telematics Engineering
- 1 100% work complete
- 2 Code Update
- 3 New video and testing
- 4 Does it move!
- 5 Code Updates
- 6 Connecting JdeRobot with 3dr Solo Drone
- 7 Updating project to JdeRobot 5.4.2
- 8 Testing 3DR Solo Drone
- 9 Updating Intel Computer Stick
- 10 Fighting Mavlink
- 11 First fly
- 12 First steps and first problems
- 13 Gradient Path Planing
100% work complete
Demo of full work integration between 3DR Solo Drone and uav_viewer in python.
After seeing in the tests some faults, the code has been modified to solve them. These failures consisted in that the phase of take off must be divided in several stages: Starting of propellers, take off and to activate the guided mode.
It has been handled as follows. The main thread will stay listening on the console the commands that can reach you, since the main thread should be the one that kills the other threads. A thread hears the commands that the main thread passes to him and the threads that are listening the ports for the commands that arrive him of speeds, position, etc.
When the take-off command arrives at the main line, a process will begin whereby the secondary wire (the one that is listening to the other commands) will prepare the take-off process, which consists, as said before in assembling the propellers, Activate the guided mode. It is not a blocking action, since the thread, will check if the time has elapsed to go to the next phase. So it has been decided that if during the takeoff phase a problem arises, it could be canceled by the main thread with a command and stop the take-off phase.
At this time there is a problem with the interface of take-off and landing buttons, you could only give that command by the takeoff and land commands in the terminal.
New video and testing
This week we tested the compatibility of the programs we have in JdeRobot to verify that they are integrating correctly. The Uav Viewer, is a program with which we can handle the dron, already supports the Parrot and our intention is that you can also connect the 3dr Solo. The tests have not been quite good since we do not detect movement but we appreciate that if we try to raise or lower the dron, sends a positive or negative signal, which leads us to think that it is an extremely low number and rounds it to 0 if Go up or -0 down. I will try this week to increase it with a multiplier to see how it behaves.
Trying other types of programs that I used last year in the subject of robotics I discovered that communication is perfect. It is not necessary to polish details like the starting of propellers, take off and landing, which part will be compacted since for the 3dr Solo Drone the fact to start the software, to start helices and to take off can be separated, to my way of seeing it would be separated in 2 , Server start-up and take-off (starting of propellers and take-off). We keep moving forward.
Does it move!
The tests have worked, had to modify the code with the found in the forum and it is mandatory to be able to move it only with speed commands that this GUIDED mode, in the first minute of the video it is seen that it does not work and then I realize , A minor nerve failure.
In the next few weeks you will think about how the dron will be handled when it takes off, whether to leave it in guided mode or anything else like that. From now on will work on a version of the code that can be controlled from an external program as already done in Ardrone Server. It is important that the code is as clean and proven as possible, this week has been the one that has taken the most important and complicated step of all.
After the holidays and the examinations I have taken up the TFG. After the failed tests of the previous weeks in which the dron did not obey the commands of speeds, I decided to investigate by Internet to see if somebody had the same problems that we.
Inquiring I found an official forum of 3dr  in which a user had performed a series of tests with commands of speed making figures. Our target is not that, but if he could move the dron from the code, that's what we are looking for and we only need to test with his code to later implement ours with commands of speeds and hook it to the software of JdeRobot.
For problems of time and not having a support to fly the dron alone, it is very dangerous to control the command of the dron, the dron itself and the computer at the same time with only two hands, I continued to investigate and it seems that many people support In the link of the forum of 3dr or that simply advise that that page of the forum is a beginning for beginners.
Github has been updated with a file and the code of that user before to test it this week.
Connecting JdeRobot with 3dr Solo Drone
These weeks I have been developing part of the code that communicates speed commands with the 3dr Solo drone. I have been doing several tests and to maintain a constant speed is created a running thread that is constantly entering the speed that we indicate, otherwise only send a speed command and then stop, is not what expected. When the command is entered, the execution thread will repeat this speed until a different speed or emergency signal is entered for the dron to stop, this last as a safety measure.
Updating project to JdeRobot 5.4.2
These weeks we decided to carry in parallel several versions of JdeRobot. Jorge needed to develop part of his code in version 5.4.0 since it was a version in which we had stable the project of MavLinkServer and the vision tests began. For my part I decided to migrate ALL the code to version 5.4.2 of JdeRobot, which includes, among other things, python3.5 and its awful file dependencies, already deprecated packages, etc ...
After 3 weeks without much advancement I have managed to maintain a stable version that runs in python 3.5  and is able to respond to simple commands. It can not be given speeds commands, is currently implementing this speeds api so that in a future can be teleoperated through a joint script to analysis of vision led by Jorge.
Testing 3DR Solo Drone
This week we have been testing more thoroughly JdeRobot packages, namely the IMU (inertial measurement unit). We set up the drone with uav_viewer package. As you can see in the video , we have some measures position of the drone and if he turns, bends, rises or any movement relative to the drone, is reflected in the indicators.
On the other hand we continue testing MavLinkServer. In this case we went outside to try to start it first with the command and then without. In the first video , we started the helices with the FLY button on the remote and we take off and land with the commands:
- Taking Off: takeoff [axis meters]
- Landing: land
Following tests try to discover how to start the helices and disable the GPS option as indoors was not possible to start it if was not GPS signal.
As you can see in the videos   I will get off the ground without using the boot command and propellers indoors.
- Remove GPS: arm uncheck gps
- Start engines: arm throttle
Updating Intel Computer Stick
In a meeting with Jose Maria through the halls of the university commented that the package that both were waiting for jderobot for version 16.04 of ubuntu just have been deployed. The facility seemed simple, do "sudo apt-get install jderobot" very simple, the problem was that when trying to tinker to install the previous version of jderobot, who had no support in the latest version of ubuntu, had bugs in packages, enough. As the Intel practically had not touched, other than trying to install jderobot, decided to reinstall ubuntu 16.04 as before, I do not get over 30 min. To some tests connect a webcam and run the typical example of cameraserver and cameraview successfully but with a low rate of fps and moments that seemed disconnected. It can be caused by several options, the webcam is old and could be broken, it may be that the intel, having connected a keyboard, mouse, webcam and USB, no more than if and so seem to jerk the images, or there is a problem with jderobot packages, investigare more thorough testing different webcam and giving more breathing space to Intel.
In previous meetings with Jose Maria we commented that our starting point of code, would be a TFG Jorge Cano . He is a student of aerospace that has created its own drone and use Mavlink. Apparently the TFG could only give cordenadas and the drone itself performed the circuit would happen but I had a problem, he could not be controlled dynamically. Orders have speeds in any direction and scale errors can not be tamed. Our starting point will be to try to understand your code, connect to 3DSolo and responsive to the coordinates we pass it, like towards Jorge Cano, only in order to fully understand every part of your code and the implication of jderobot in, commands such as speed or position having the drone at the time.
Seeing with Jorge Vela TFG Jorge Cano, and seeing part of the code, were the configuration files as scripts and other writings in windows, our drone, as I have said on previous occasions is intended to run on an Intel running ubuntu 16.04 . Which brings us having to wipe us well the code looking for any type of connection with Windows and Unix suit.
Testing their code were not able to initialize and say take a different route because we would save a lot of time. We took the code to use as a base ArduPilot has to Mavlink and introduce the changes that have as imported classes jderobot and we managed to respond to commands restart. In future attempts we will connect the helices and try to do a controlled launch in external laboratories to ensure that we are actually able to connect from our computers to drone through Mavlink.
At this point it joined Jorge Vela, the idea will be the same but we want to expand and do a more extensive TFG. To do something interesting in its early days we set to work to try to blow up the 3DSolo, without much success. We had to unburden the official application so he could fly, update software and remote control drone (the most current at the moment) version 2.4.2. We did a test in the laboratory and could not get to order the drone, even takeoff. At first we thought it could be failure of our phones until researching and moving the drone site, we realized we needed to detect GPS signal. This signal must detect the drone (this transpired trial and error moving site command and drone). To make the first flight we left the campus and connect only the drone and the control which controls the mobile was not necessary because it only serves to transmit the images that collected with the camera. The first flight was pure fun and scary at the same time, we had to try but not break. At this point we saw the connection that perform the control and the drone is via Wifi but it is mandatory to have GPS signal, detects another way you can be in a closed and has given the power would destroy the drone bumping into place.
First steps and first problems
The idea of this TFG consist in using a Quadricopter indoors. To make a first test I will use the 3dr Solo. In this Quadricopter is introducirar a GoPro, an Intel Computer Stick and a camera with vision RGBD (Kinnect). To be taking ease with JdeRobot in Quadricopter installing Ubuntu on Intel Stick is prioritized.
Here begin the first problems, the specifications of the Intel Stick that will be used are attached in the photo . When trying to install Ubuntu, the main problem was that the boot loader is not detected and pedia again and again to reinstall. I asked for help from Francisco Perez (developer JdeRobot) and thanks to find the error, the BIOS was outdated.
At first the version of Ubuntu 14.04 was installed as JdeRobot had created packages and support. This idea has been discarded since the package for Ubuntu 16.04 version of JdeRobot will be created in a few weeks.
The installation of version 16.04 was not easy because I did not have modules to access the Intel Stick via WiFi or Bluetooth. Reconnects with Francisco suggested I install a version that was in the URL  and that was achieved successfully installed.
Gradient Path Planing
To carry out this technique based navigation maps have followed the following steps. In the map on the right just any position, which is marked with a red X mark . When the path generate a ' wave " which is propagated values , which we always stay with the maximum value between the nearest points plus the sum of the corresponding value is generated. From these values it receives will stay with the maximum . In the case that a point is near a wall, you should decrease its value , since it is a point of conflict and could have collision. When we reached the point destination to the source , will travel the opposite way , but with a dot matrix which will travel to the positions whose value is the maximum , indicating that is closer to the destination than any of the other points and therefore We will travel a shorter path.