Jessica
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:
http://www.icornerhightech.cz/
… 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 parse.py.
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.
Blog
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 http://gradle.org/docs/1.12/userguide/gradle_daemon.html 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 gradle.properties file in the project:
org.gradle.jvmargs=-Xmx512m -XX:MaxPermSize=512m
I did not have any file named gradle.properties, 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
SampleGattAttributes.java. 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 DeviceControlActivity.java):
//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 ); mBluetoothLeService.writeCharacteristic(characteristic); // end of hacking
and changes of BluetoothLeService.java
public void writeCharacteristic(BluetoothGattCharacteristic characteristic) {
if (mBluetoothAdapter == null || mBluetoothGatt == null) {
Log.w(TAG, "BluetoothAdapter not initialized");
return;
}
mBluetoothGatt.writeCharacteristic(characteristic);
}
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() ) {
descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);
mBluetoothGatt.writeDescriptor(descriptor);
}
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
parse.py
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
icornerhightech.cz 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:
!!! PARROT RELEASED ARDroneSDK3 !!!
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.