czech english


indoor minidrone from Parrot

Parrot minidrone (Rolling Spider) is my current toy. The primary motivation is preparation of a demo for the contest of autonomous robots Tour the Stairs (part of robotic festival at the end of November in Prague). Anybody interested in decoding communication before SDK will be freely available? Blog update: 4/12 — Parrot released ARDroneSDK3!

Here are the first pictures:
The drone was lend from Czech Parrot distributor:
… and here is the link where hopefully will be SDK from Parrot one day:
Currently you will find there: Note: this is not the Software Development Kit (SDK) for developing applications to control the drone from a remote device. The SDK will be released at a later time.
Unfortunately we have tight dead-line, because Tour the Stairs is by the end of November 2014 and the situation with SDK probably won't change.

Bad news

Rolling Spider uses Bluetooth 4 = BLE, which means Bluetooth Low Energy. This sounds like an interesting new technology but for example my Windows 7 does not support it (update: it looks like there are some new drivers). On the other hand the other notebook with Windows 8 behaves like it could potentially talk to the drone.
Rolling Spider comes with application Free Flight 3, which is nice, but … in order to talk to the drone you need not only BT4 but also your device has to be in a relatively short list of supported devices:

Good news — btsnoop_hci.log

There is a hope and it has name btsnoop_hci.log . What is it? Since Android 4.4 there is a new tool for Bluetooth capture communication (see this article). Just check in Developer options option Enable Bluetooth HCI snoop log and whole communication is logged into the file btsnoop_hci.log. Cool isn't it?!
No idea what to do with it? Well, there has to be coded info why drone refuses other phones, commands to fly, termination of communication, etc. At the moment I have couple logs from two different phones. If you want an example here is one log from Samsung S4 (well I am not sure what kind of "secret" information is hidden there). It was just on/off and once I accidentally touched the display and the propellers turned a little … and it has 140kB, sigh.
The parsing is relatively simple. It contains timestamps, how many bytes are transfered and in which direction. Here is new Jessica's repository on github with simple
If you have phone with Android 4.4 and would like to repeat what I did, here are two important details:
  • the default phone menu does not contain Developer options
  • btsnoop_hci.log is not necessarily at /sdcard/btsnoop_hci.log
The first thing was simple — the answer is for example here. It is necessary to press seven times in About phone otherwise gray Build number and you will see You are a developer!
The hint about exact absolute path was written in already mentioned article. In reality it was /sdcard/Android/data/btsnoop_hci.log, but it can be different on every system. In particular it is necessary to look in file /etc/bluetooth/bt_stack.conf and there you will find it. If you have problem how to look at this directory you can use for example Total Commander.


5th November 2014 — BLE, BLE, BLE

It is too early and there are no suitable „ready to use” tools. I am giving up combination "Bluetooth 4 BLE Python Windows 7". It looks like there is only one Python wrapper supporting Bluetooth Low Energy for Linux (bluepy), but that is basically wrapper for bluez. It could be a source of inspiration though like list of services UUIDs.
The way to go now is to get running BluetoothLeGatt example for Android 4.3+ in Java. GATT seems to be an important word — Generic Attribute Profile used for BLE. It would be just too simple to use the sample: Note: At this time, the downloadable projects are designed for use with Gradle and Android Studio. Project downloads for Eclipse will be available soon! (taken from samples page).
And what I am trying to do? Well, it would be a bit useless to fully understand the btsnoop_hci.log if I would not be able to replay it. So that is the plan — record some minidrone action with logging facilities and then replay it on the same phone, where it should be hopefully work. And then, in the next phase, try to understand the command details.
p.s. obviously I am not the only one, who is looking for Python BLE libraries

7th November 2014 — Android Sample

I have to write down some notes, because you would not be able to tell that there was some progress (especially if there are no new commits on github). The good news is that I managed to get working Android Bluetooth LE Sample. I was not „click and go” — instead that was a kind of blind fight with installation, drivers, etc.
At the end I decided to try Android Studio. I am still not sure if I was supposed to use studio.exe directly or studio.bat, but now I have set path to Java SDK (the bat wrote: ERROR: cannot start Android Studio. No JDK found. Please validate either ANDROID_STUDIO_JDK, JDK_HOME or JAVA_HOME points to valid JDK installation.) and I also overcome problem in studio itself:
Error:Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at
Please read below process output to find out more:
- - -  - - - - - - - -  - - - - - -  - - - - - -
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
The solution for this was found on stack overflow: to add something like this to your file in the project:
org.gradle.jvmargs=-Xmx512m -XX:MaxPermSize=512m
I did not have any file named, but details where such a file could be you can find in gradle documentation.
So what the Bluetooth sample does? It scans for BLE devices, if you select one it connects to it and list available services, and if you select service it can read given server (e.g. minidrone) characteristics. I probably mismatched exact Bluetooth terms, but what I mean is that you can connect to the drone and ask what it can do. And surprisingly enough 80% (?) of initial communication is identical to Free Flight 3!
The conclusion is that it is not only „decoding Parrot protocol” but rather understanding GATT and Bluetooth LE protocol (which is good and bad news in one). For me this is completely new area, but the motivation is relatively strong to learn more. An interesting online book with reasonable explanation is here, Chapter 4. GATT (Services and Characteristics).
A funny note at the end of this update … as I am decoding communication bottom up it is fun to discover messages like this (two different phones): [2, 64, 32, 17, 0, 13, 0, 4, 0, 9, 11, 22, 0, 71, 97, 108, 97, 120, 121, 32, 83, 52] and [2, 64, 32, 27, 0, 23, 0, 4, 0, 9, 21, 22, 0, 76, 106, 32, 67, 114, 101, 97, 116, 111, 114, 32, 40, 71, 97, 108, 97, 120, 121, 32]. Do you see there some similarity? And what about [2, 64, 32, LEN=27, 0, LEN=23, 0, 4, 0, 9, LEN=21, 22, 0, 76, 106, 32, 67, 114, 101, 97, 116, 111, 114, 32, 40, 71, 97, 108, 97, 120, 121, 32]. So it is envelop of envelop for envelop for string. Almost half of transmitted bytes are length of sent buffer.

9th November 2014 — GATT, Services, Characteristics, …

It is quite hard for me to read through Bluetooth LE specification. The bits slowly fit into the whole image, after many reading attempts. Everything is written there just my brain somehow refuses to understand it .
Now I would like to say that the best start is probably wikipedia Bluetooth Low Energy article. Note, that you have to understand the BLE concept if you want to understand Parrot minidrone protocol, so that's why I am trying „so hard” .
GATT, Services, Characteristics, … these are all keywords used in BLE. GATT is an acronym for the Generic Attribute Profile, and it defines the way that two Bluetooth Low Energy devices transfer data back and forth using concepts called Services and Characteristics. It makes use of a generic data protocol called the Attribute Protocol (ATT), which is used to store Services, Characteristics and related data in a simple lookup table using 16-bit IDs for each entry in the table. (source) Clear?
I cannot find now mine „eye opener” image/table so at least one more complicated: source.
So GATT is based on existing L2CAP (Logical Link Control and Adaptation Protocol) which is something similar like UDP on Internet communication (and it is not available under Microsoft Bluetooth Stack, as far as I understand it). For night reading I would recommend Bluetooth for Programmers PDF from MIT — a bit older with many TODOs, but still good enough. There you will learn about L2CAP.
Does it help? Well not really. It means that if I would be able to send packets via L2CAP I should be able to replay logged data as-it-is. Maybe. But if I want to use GATT available in Android, for example, then it is necessary to understand the protocol in more details and go to the ground what each byte means.
I would pick some (for me important) sentences from wikipedia:
  • Bluetooth Smart is not backward-compatible with the previous Bluetooth protocol. Bluetooth Smart uses the same 2.4 GHz radio frequencies, but it uses a simpler modulation system. (i.e. not good idea to convince old hardware to talk with BLE)
  • Write operations always identify the characteristic by handle, but have a choice of whether or not a response from the server is required. (So it is not enough to know characteristics by its UUID, you need to find the handle.)
Now back to the minodrone. If you run Android Bluetooth LE sample, you will find a big list of available characteristics (32+32+7=71 in total). The complete list is in modified But how to find which UUID corresponds to the „magical command” for motion control, mentioned sooner? After some experiments with write it looks like that the assert with array [0x12, 0x0, 0x4, 0x0, 0x52, 0x40, 0x0, 0x2] contains the 16bit handle [0x40, 0x0].
How to write characteristics? This part is missing in the example, but you can find the answer here.
This was my hack (modification of
//hack mBluetoothLeService.readCharacteristic(characteristic);
// hacking
byte[] value = new byte[5];
value[0] = (byte) (0x11);
value[1] = (byte) (0x22);
value[2] = (byte) (0x33);
value[3] = (byte) (0x44);
value[4] = (byte) (0x55);
characteristic.setValue( value );
// end of hacking
and changes of
public void writeCharacteristic(BluetoothGattCharacteristic characteristic) {
    if (mBluetoothAdapter == null || mBluetoothGatt == null) {
        Log.w(TAG, "BluetoothAdapter not initialized");
If you look in btsnoop_hci.log you will find there 0x11, 0x22, 0x33, 0x44, 0x55:
[0x2, 0x40, 0x20, 0xc, 0x0, 0x8, 0x0, 0x4, 0x0, 0x52, 0x22, 0x1, 0x11, 0x22, 0x33, 0x44, 0x55]
[0x2, 0x40, 0x20, 0xc, 0x0, 0x8, 0x0, 0x4, 0x0, 0x52, 0x25, 0x1, 0x11, 0x22, 0x33, 0x44, 0x55]
I was sending this array at first to characteristics D52 and D53 (the only difference is 0x22 and 0x25), but then I tried Axx characteristics (there are 32 of them) and got
[0x2, 0x40, 0x20, 0xc, 0x0, 0x8, 0x0, 0x4, 0x0, 0x52, 0x22, 0x0, 0x11, 0x22, 0x33, 0x44, 0x55]
[0x2, 0x40, 0x20, 0xc, 0x0, 0x8, 0x0, 0x4, 0x0, 0x52, 0x25, 0x0, 0x11, 0x22, 0x33, 0x44, 0x55]
At first moment I was quite disappointed that I am getting the same numbers as for D52 and D53 and that it is probably dynamically assigned … but I overlooked 0x1/0x0 difference . And handle is 16bit, so the treasure has UUID=9a66fa0a-0800-9191-11e4-012d1540cb8e.
p.s. do not ask me if it is already flying — it is not :-( … not yet.
p.s.2 one implementation note, which could be useful the advertisement packet is composed of a series of variable length blocks, that can appear in any order. each block starts with a length byte, followed by a type byte, followed by the data. the payload cannot exceed 31 bytes. … taken from RFduinoBLE github … but maybe it is not related.

11th November 2014 — Cracking Handles

Thanks to Šimi I realized why I was not able to find handles (16bit identification of characteristics) for Bxx services. The reason are GATT PROPERTIES. It struck me out when I saw in debugger that mProperties differ:
mUuid = {java.util.UUID@830047596672}"9a66ffc1-0800-9191-11e4-012d1540cb8e"
mService = {android.bluetooth.BluetoothGattService@830047490720}
mProperties = 12
mPermissions = 0
mKeySize = 16
mInstance = 0
mWriteType = 1

mUuid = {java.util.UUID@830047598160}"9a66fd22-0800-9191-11e4-012d1540cb8e"
mService = {android.bluetooth.BluetoothGattService@830047491960}
mProperties = 30
mPermissions = 0
mKeySize = 16
mInstance = 0
mWriteType = 1
The bit array is following:
public static final int PROPERTY_BROADCAST = 1;
public static final int PROPERTY_EXTENDED_PROPS = 128;
public static final int PROPERTY_INDICATE = 32;
public static final int PROPERTY_NOTIFY = 16;
public static final int PROPERTY_READ = 2;
public static final int PROPERTY_SIGNED_WRITE = 64;
public static final int PROPERTY_WRITE = 8;
public static final int PROPERTY_WRITE_NO_RESPONSE = 4;
So some characteristics you can write only, some can be read only, etc. And mine piece of code was in "if can read" condition:
final int charaProp = characteristic.getProperties();
if ((charaProp | BluetoothGattCharacteristic.PROPERTY_READ) > 0) { … }
(I am not Java programmer, but this bit operation would be wrong in C … I would guess that there should be & instead … this is taken from the Android Sample)
What I am up to is to find handle for all UUID, and after reading this webpage I was looking for another way: 2. The Android BLE developers chose to use UUID as the characteristic identifier in GATT API's; handles are not directly exposed to applications. Internally, Android maps UUID's to handles and uses handles to access characteristics, but apps have no need to know the handle. … so it is not a good idea to search for it in Android Java.
The good news is that you can find it in btsnoop_hci.log. I wanted to know handle for 9a66fa0a-0800-9191-11e4-012d1540cb8e (I know this one, it is 0x40). All you need is to search for "0a fa 66 9a" (reversed order), and you will find 02 40 20 1B 00 17 00 04 00 09 15 3F 00 04 _40 00_ 8E CB 40 15 2D 01 E4 11 91 91 00 08 0A FA 66 9A
… so now I have all handles of all characteristics + their properties .

12th November 2014 — Missing handles and more UUIDs

OK, now I think that I can finally generate identical output as FreeFlight3. But it was not that easy. Where was the problem? Well I could not get this output section:
02 40 20 09 00 05 00 04 00 12 C0 00 01 00
02 40 20 09 00 05 00 04 00 12 BD 00 01 00
02 40 20 09 00 05 00 04 00 12 E4 00 01 00
02 40 20 09 00 05 00 04 00 12 E7 00 01 00
02 40 20 09 00 05 00 04 00 52 16 01 01 00
02 40 20 09 00 05 00 04 00 52 26 01 01 00
The last two "packets" have 0x52 which is similar to
02 40 20 0A 00 06 00 04 00 52 7C 00 01 01 01
… and this means write 01 01 01 to handle 0x7C. So in previous section this should correspond to "write 01 00 to handle 0x116". Well, but there is no such UUID, which would correspond to handle 0x116!? :-(. Do you know the answer? I did not. The major hint was BLE_SensorTag_GATT_Server.pdf where I found Client Characteristics Configuration --- Write "01:00" to enable notifications, "00:00" to disable notification. I supposed that the Android Sample is already sending notifications but it was only for some special UUID_HEART_RATE_MEASUREMENT.
The code was replaced by:
for( BluetoothGattDescriptor descriptor : characteristic.getDescriptors() ) {
And then I tried nearby handles, and it worked .
Remained 4 packets with 0x12 instead of 0x52. They belong to Bxx section where only PROPERTY_NOTIFY = 16 is set. Tried that and it worked too although the offsets were a bit different. Here is the diff for Bxx notifications.
And one small bonus — I was tired of watching the minidrone LEDs, so last night I started FreeFlight3 again and just spin the propellers . And there was a difference when compared to old the logged output:
02 40 20 18 00 14 00 04 00 52 43 00 04 01 00 04 01 00 32 30 31 34 2D 31 31 2D 31 31 00
02 40 20 1A 00 16 00 04 00 52 43 00 04 02 00 04 02 00 54 32 32 33 32 33 38 2B 30 31 30 30 00
02 40 20 0D 00 09 00 04 00 52 43 00 04 03 00 02 00 00
Guess, what is it? 0x30-0x39 are numbers … 2014-10-29 and T223238+0100 is better? So UUID 9a66fa0b-0800-9191-11e4-012d1540cb8e is Date/Time.
Now it is time to put it all together and replay it with 50ms sleeps (at least it looks like the messages are sent with 20Hz frequency).
p.s. I skipped bad news — I bought USB BT400 to enable Bluetooth 4.0 on my old laptop with Ubuntu Linux, fixed some issues with driver, but the drone refused to connect anyway …

13th November 2014 — The First Spin

Yesterday morning I finally managed to spin the propellers . Why it did not work sooner I am not 100% sure, but it could be due to timing (before I was sending messages without pause) and I had mistake in selected increasing byte, which was maybe in previous version too.
I decided to put even non-modified source on the github (diff), so if you want you should be able to repeat my steps. Please let me know if you encounter any problem.
I tried to record a demonstration video this morning, and sure enough it did not work. There is still a big TODO for version 0 (homologation, climb one step) and it is necessary to be able to stop the robot. There will be new application button for "Tour the Stairs", but it is not there at the moment, so what you need to do is enable notifications via B01 service, B0E characteristic — and that works:

14th November 2014 — Not there yet

This is the first attempt for version 0 Tour the Stairs code. And it is not working, yet. The drone moves slowly towards the step (beware, if you would like to repeat my attempt do not forget to attach wheels and configure the minidrone to use them), but then it fails to fly a little bit up. The step friction is too big. You can take off in free area but it is a bit scary/dangerous.
Note, that now two more bytes are correctly interpreted (see diff). Instead of 16bit value there are two 8bit values, turn right/left and up/down. Both values are probably percentage, i.e. 100 is maximum and you can use -100 for opposite direction.

15th November 2014 — Hints

I am no longer alone to fight this minidrone-stair-climbing task . And the other guy knows some great details.
For example, I can confirm that the last four bytes in AT*PCMD should be interpreted as a float number. I am still not absolutely sure what it does (I have to test it) — it is probably a multiple for other byte parameters? Do you remember me about writing that first 16bit number looks like forward speed (see forum)? Well, I was wrong. The same command is used also for flying and there would be missing parameter for tilt left/right. When you are rolling on the wheels you will not notice it (yeah, I am just trying to find an excuse ). Now I tried to replay all my old FreeFlight3 logs and I can confirm that both forward/backward and tilt left/right values are within range -100..100 (see fixed diff).

20th November 2014 — Takeoff and landing

You probably noticed that there was no „homologation video” posted till the deadline 17th November 2014 :-(. I overcome some problems like interpretation of the first two bytes in AT*PCMD command: when I send 8000 as 16bit integer it moved in reasonable speed forward, but when I set only byte part of it (hex(8000)='0x1f40', i.e. 0x40 and 0x1F) and the second byte zero then it did not move at all. The explanation was easy — it is not the first byte for the moving forward, but the second byte. And tilt byte helped to roll.
A friend of mine (PetrS) suggested to use nicer code via ByteArrayOutputStream and DataOutputStream but I did not properly solve endians for the float number (see diff).
So what is the problem? I switched to manual control and used FreeFlight3 and I did not manage to climb the step even with several attempts. Sigh. So it is hard to convince the machine to do it autonomously if I cannot do it manually. Note, that I was only driving on the floor and near the step I switched to full power up but it hardly lifted and it looked very dangerous.
My last chance is to fly to the upper step. So last night I pushed takeoff and a second later land. I was very very surprised how smoothly it went up and down when compared to older AR Drone 2.0. Again I parsed btsnoop_hci.log and I found there these new commands:
02 40 20 0D 00 09 00 04 00 52 43 00 04 05 02 00 01 00
02 40 20 0D 00 09 00 04 00 52 43 00 04 06 02 00 03 00
02 40 20 0D 00 09 00 04 00 52 43 00 04 07 02 00 03 00
The first is takeoff but I was not sure which one is landing. Note the 5th number from the right — it is again increasing like for AT*PCMD and 0x43 is actually handle for settings. See older post and compare this handle with setting date and time . So landing command was pressed twice.
Now it is early in the morning so I do not want to try autonomous takeoff/landing but I will probably publish the code, so if there is anybody interested you will know what I am talking about.
The plan is to takeoff to 20cm, fly forward and land. Unfortunately I did not find out how to collect data like altitude, absolute position, even if the takeoff/landing is complete … so it will be controlled only by time. At the moment it is probably „the simplest thing which could possibly work” .
p.s. sure enough it flew to 1 meter and then it refused to land … I am glad that the old trick that you take the drone by the frame (here wheels) and turn it up-side-down works

21th November 2014 — Emergency Stop

Last night I confirmed that it was not an accident that Rolling Spider did not want to land shortly after takeoff but „feature”. I tried to repeat landing during takeoff in FF3 (Free Flight 3), and it does nothing until you finish the takeoff sequence.
So there are two possibilities now:
  • climb the stairs with 1m high takeoff/land sequence
  • use Emergency Stop to cut all motors even during takeoff
The byte-sequence for Emergency Stop is:
02 40 20 0D 00 09 00 04 00 52 46 00 04 01 02 00 04 00
02 40 20 0D 00 09 00 04 00 52 46 00 04 02 02 00 04 00
So it is again another handle (0x46) and it has its own counter (5th byte from the end) — very similar to takeoff/land.
This code managed to „jump” on the step (the AR Drone 2.0 paper box), but it failed during video recording and now the battery needs recharging … so next test tomorrow.

23rd November 2014 — Battery packet

A few days ago I came across these inputs:
71.973 1: 02 40 20 0E 00 0A 00 04 00 1B BF 00 02 06 00 05 01 00 5F
72.108 1: 02 40 20 0E 00 0A 00 04 00 1B BF 00 02 07 00 05 01 00 5E
72.940 1: 02 40 20 0E 00 0A 00 04 00 1B BF 00 02 0E 00 05 01 00 57
The log was from experiment in FreeFlight3 with takeoff and I remembered that battery status was at the end 87%. The last number in the packet was decreasing by one and the last one 0x57 is 87 … so I think that now we have „battery packet”.
It was necessary to add more notifications (see code). The plan is to enable notification all available handles but time is getting short (the contest is on 29th November 2014). At least I finally recorded homologation video („jump” one step).

24th November 2014 — RC toy?! (5 days)

Bad news — it looks like that current version of Rolling Spider does not support sending of speed/position/altitude status :-(. The machine has to know it but it is not necessary for Free Flight 3 application. Experimentally I enabled all available notifications (see diff) and I have not see anything „interesting”.
So what can we do without any feedback? I tried takeoff with down command … crazy combination but it is still moving up anyway. What I would try is to takeoff, wait until it is flying and then move down without landing. For that we will need to know flying status.
With help it should be these messages:
0: 02 40 20 0D 00 09 00 04 00 52 43 00 04 05 02 00 01 00 = takeoff
1: 02 40 20 11 00 0D 00 04 00 1B BC 00 04 15 02 03 01 00 01 00 00 00 = takingoff
0: 02 40 20 0D 00 09 00 04 00 52 43 00 04 07 02 00 03 00 = land
1: 02 40 20 11 00 0D 00 04 00 1B BC 00 04 18 02 03 01 00 04 00 00 00 = landing
1: 02 40 20 11 00 0D 00 04 00 1B BC 00 04 19 02 03 01 00 00 00 00 00 = landed
0: 02 40 20 0D 00 09 00 04 00 52 46 00 04 01 02 00 04 00 = emergency cmd
1: 02 40 20 11 00 0D 00 04 00 1B BC 00 04 02 02 03 01 00 05 00 00 00 = emergency

25th November 2014 — Takeoff workaround (4 days)

Finally there was more serious testing today. I experimented with a takeoff workaround, i.e. complete takeoff sequence, return back on the ground with move down command and then move forward on the ground. The results were interesting:
  • sometimes notifications failed to turn on (i.e. the drone was infinitely waiting for takeoff sequence completion, or there were no data about low battery)
  • when the drone reached the ground with move down command it was oscillating back and forth for a while
  • as the battery was lower and lower the drone finished takeoff and switched to hovering even 20cm above the ground (instead of 1 meter)
The main problem was going „against the wall” without any feedback. Jessica just hit it hard and jumped back. This would mean falling down from the stairs. It is possible to limit vertical speed but the minimal value you can set is 0.5m/s. Maybe it is just limitation of Free Flight 3, and the speed could be set lower?? But the battery was dead I did not want to wait at school for 90 minutes until it would be fully charged.
p.s. one new byte sequence:
1: 02 40 20 11 00 0D 00 04 00 1B BC 00 04 04 02 03 01 00 02 00 00 00 = hovering status

26th November 2014 — Ver0 revised (3 days)

First of all I would like to thank for lending me another drone (Jessica B./Blue/Backup) and extra battery. Now I should survive 8 rounds on Saturday with much lower risk (I wanted to write „without any problem” but we all know that something will „show up”).
Second, some issues I have seen yesterday were not caused by low battery but by re-starting the testing application. If I turn the minidrone off and on again it works usually fine.
Third, I wrote usually because once it did not work fine and I experienced very ugly crash. Even the wheels and one propeller fell off :-(. Maybe bad calibration at the start?? The drone just went in 20deg angle instead of vertical takeoff, hit the wall and fell on the ground. It still runs fine, so the mechanics is very robust!
I do not know if I mentioned battery and status info in the testing application. Now you can see if there are any updates coming, if the status is changing and how much battery is left.
Today we were testing in NTK Gallery and I had to tune ver0 — if there were 15 repetition Jessica jumped to 2nd step instead of 1st one. 12 repetitions = 0.6s was mostly just right, but when the battery was at 58% Jessica was not able to climb the step (sure enough in front of TV camera).
Because of the scary experience with one takeoff I will probably continue from ver0 (see function ver0ex(), where I called ver0 three times but I was not able to reach the 3rd step yet). So takeoff while moving forward and emergency stop is the way.

28th November 2014 — !!!STOP!!! (1 day)

Tonight I was preparing „contest version”. It was is not very great, but just a few changes to the last commit:
  • STOP button has to be separate — the drone is dangerous and it is very bad to guess it you switched it on or off
  • if you disconnect and connect again it works fine as if you reset the drone
  • the height of takeoff during first 12/20 to 18/20 seconds is quite random and probably depends on friction of the wheel with the step, battery status, … ???
  • Jessica Blue can be controlled with the same program but while the Red One flies almost 20cm the Blue One hardly took off 5cm … so I will use it as charger only.
  • I swapped approachStep with ver0 so there is at least a chance to score for the first step

30th November 2014 — Tour the Stairs

The competition Tour the Stairs is over. Jessica finished on 4th place (i.e. the last place) but I would still consider it success. In the best attempts she was able to jump/climb two steps, but emergency stop cutting the power to stop takeoff always disturbed it too much.
For the last two runs (straight and spiral staircase) the other team from Písek convinced me to try „prohibited” strategy with a rope. It was attached in the battery holder and it was approximately 1m long. I changed the code (see diff) to complete takeoff and to fly forward with power set to 10%. Now the hardest part was to enter the staircase (there were railings on both sides). Once it succeeded it was really superior to previous approach — I cut the first try on the staircase rest area but after the contest, just for a video documentation, Jessica was able to climb the whole staircase .
So there is another difference between old AR Drone 2.0 and Rolling Spider (I think that this change was also between old AR Drone and the next generation). As I said I was flying forward only but I never hit the steps. So the altitude is only relative and not absolute to the ground as for AR Drone 2.0. On the other hand it could be caused by sensor confusion because of the rope (bad sonar or camera readings?) so I am not sure.
What next? Well, I hope I receive some videos of the contest (the official one will be in January, but something else could be next week). And that is going to be end of this blog (both drones will be returned this Tuesday).
p.s. I still hope that Parrot will revise the firmware to send drone data (time, speed, altitude, reading from sonar and camera, estimate of position) and that it will be possible to stream some pictures over Bluetooth (now you can save them and then transfer them but I did not try that during flight yet).

4th December 2014 — Parrot released ARDroneSDK3!

Today I received two interesting e-mails related to Rolling Spider. The first one pointed me to another github repository … so somebody else was trying to modify Android BluetoothLE example like me .
The second mail trump the first one:


It is probably not publicly announced yet (?), but the github is ready. If you are lost in these tons of source code I would recommend to start from ARDrone3_commands.xml, where are all commands shortly described.