Failure to obtain Bluetooth responses from a CrazyFlie 2.0 running the ravenscar-cf-stable branch

[mayeroa]

Hello, AdaCore wizards.

We are trying to establish communication with a CrazyFlie 2.0 running the “ravenscar-cf-stable” branch of your CertyFlie.

To establish a working baseline, we first built the manufacturer’s firmware with CLOAD=0, to include the radio bootloader. We then flashed it to our CrazyFlie with dfu-util, and were able to run the examples/basiclog.py to establish BlueTooth communication with the Flie and get back stabilizer's roll/pitch/yaw values. So both our HW and our development toolchains appear to be properly setup.

Being fans of Ada, we would prefer now to use the CertyFlie code to control the copter; so we installed the GNAT GPL 2016 toolchain, and built the CertyFlie’s “ravenscar-cf-stable” branch:

$ gprbuild -P cf_ada_spark.gpr -p

$ ls -l obj/cflie.elf
-rwxr-xr-x 1 taste taste 1577600 May 19 15:35 obj/cflie.elf

We flashed the result on the CrazyFlie with dfu-util, and a quick “just drop me” test proved that your free-fall functionality is fully operational.

Unfortunately, the BlueTooth part doesn’t seem to communicate with “basiclog.py”… To see exactly what is happening, we placed a breakpoint with GDB on line 70 of crtp.adb ...

task body CRTP_Rx_Task is                                                               
   Packet : CRTP_Packet;                                                                
   Has_Succeed : Boolean;                                                               
begin                                                                                   
   loop                                                                                 
      Link_Receive_Packet_Blocking (Packet);                                            
                                                                                        
      if Callbacks (Packet.Port) /= null then     <========= HERE ======
         Callbacks (Packet.Port) (Packet);                                              
      else                                                                              
         Port_Queues (Packet.Port).Enqueue_Item (Packet, Has_Succeed);                  
      end if;                                                                           
   end loop;                                                            

...to see the CRTP packets coming over BlueTooth:

$ # AND WHEN WE BREAK, WE PRINT THE “Packet” VARIABLE
$ cat gdb_script.cmd
set pagination off
tar extended-remote :2331
monitor reset
file cflie.elf
load cflie.elf
b crtp.adb:70
commands 1
        silent
        echo Just received a CRTP packet
        p Packet
        cont
end
c

Running the firmware under this GDB script, we see this output:

$ arm-eabi-gdb -x gdb_script.cmd cflie.elf

GNU gdb (GDB) 7.10 for GNAT GPL 2016 [rev=gdb-7.10-ref-161-g9bf8eca]
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
See your support agreement for details of warranty and support.
If you do not have a current support agreement, then there is absolutely
no warranty for this version of GDB.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-eabi".
Type "show configuration" for configuration details.For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cflie.elf...done.
0x00000000 in ?? ()

Resetting target
Loading section .text, size 0x471b8 lma 0x8000000
Loading section .ARM.extab, size 0x446c lma 0x80471b8
Loading section .ARM.exidx, size 0x3f30 lma 0x804b624
Loading section .rodata, size 0x9a60 lma 0x804f558
Loading section .data, size 0xc80 lma 0x8058fb8
Start address 0x80399fc, load size 367668
Transfer rate: 32640 KB/sec, 3996 bytes/write.
Breakpoint 1 at 0x800e160: file /home/taste/GitHub/Certyflie/modules/crtp.adb, line 70.

Just received a CRTP packet$1 = (size => 0, channel => 3, reserved => 0, port => 
crtp_port_link, data_1 => (11, 248, 172, 59, 12, 128, 184, 58, 0 <repeats 22 times>), 
header => 243, data_2 => (11, 248, 172, 59, 12, 128, 184, 58, 0 <repeats 22 times>), 
raw => (243, 11, 248, 172, 59, 12, 128, 184, 58, 0 <repeats 22 times>))

Just received a CRTP packet$2 = (size => 0, channel => 3, reserved => 0, port => 
crtp_port_link, data_1 => (76, 203, 134, 64, 12, 128, 184, 58, 0 <repeats 22 times>), 
header => 243, data_2 => (76, 203, 134, 64, 12, 128, 184, 58, 0 <repeats 22 times>), 
raw => (243, 76, 203, 134, 64, 12, 128, 184, 58, 0 <repeats 22 times>))

Just received a CRTP packet$3 = (size => 0, channel => 3, reserved => 3, port => 
crtp_port_link, data_1 => (76, 203, 134, 64, 12, 128, 184, 58, 0 <repeats 22 times>), 
header => 255, data_2 => (76, 203, 134, 64, 12, 128, 184, 58, 0 <repeats 22 times>), 
raw => (255, 76, 203, 134, 64, 12, 128, 184, 58, 0 <repeats 22 times>))
...

At this point, lines like the above (“received CRTP packet”) will keep appearing, until basiclog.py stops waiting and aborts. So, BlueTooth communication seems to be working in the direction PC with BT dongle => CrazyFlie,, but apparently not in the reverse direction - that is, there are no responses coming back to the script.

Can you please indicate if you see something wrong with our approach above?

And is the CertyFlie firmware supposed to be able to reply to these requests from “basiclog.py”? If not, is there any other way we can establish bi-directional communication with the CertyFlie firmware?

Thanks in advance for any help/pointers,
Alexander.

[AnthonyLeonardoGracio]

Hello Alexandre,

Thank you very much for your investigation. Actually, I have never succeed to log values in the Crazyflie PC client, but I did not have time to investigate more at the time. Your investigation seems to indicate that the problem is a bit larger than what I thought, since no packets are received by the client, and not only the ones that concern logging.

Your approach looks fine, but there's definitely something wrong in the firmware for sending packets. Or maybe the packets we send don't have the format expected by the client, leading them to be dropped by the client...

[simonjwright]

I've been looking at this over at my fork, branch logging, with partial success. By that I mean, I can get the PC client (cfclient) to connect and return data for a while (over CrazyRadio PA), but after a minute or two it drops out (the client remains connected, but the drone doesn't receive commands).

The problems I've identified are, in approximate order:

• DMA to the NRF51 has to be flow-controlled.
• You have to be responsive communicating with the NRF51; at one point it seemed that if I compile with -O0, for debugging, the drone would lock up so that I had to power off/power on rather than just resetting via the debugger. -O2 was OK. At the moment I'm running with Ada_Drivers_Library built with -O2 (PLATFORM_BUILD set to Production, BUILD set to Debug) and things are OK. I interpret this as the NRF51 getting terminally confused because the STM32F4 wasn't responding quickly enough.
• The group/variable name sent to the client has to have each component nul-terminated: group_name & ASCII.NUL & variable_name & ASCII.NUL.
• For a group to be used, it must contain all the names expected by the client.
• Variables can be in more than one block.
• The Block_ID sent by the client can't be used as an index: if the client uses blocks IDs 0, 1, 2, 3 and then disconnects/reconnects, it'll use block IDs 4, 5, 6, 7.
• Blocks mustn't be sent from Timer_Events, which run at very high (interrupt) priority. I just put the block ID in a PO, retrieved by a low-priority task (and discarding any overruns).
• As well as log info, cfclient needs to see memory info and parameter info before it starts exchanging data (it works fine with a response of 0 to MEM_CMD_GET_NBR; that might have worked for parameters too, but I implemented one anyway).

Notes on changes:

• Added LEDS.Flasher, to allow easy flashing of an LED for 5 ms.
• Fixed Parameter (still had the old name).
• Moved the private parts of Log, Parameter to the bodies.
• Reworked Log using Bounded_Strings and Containers (now uses new Generic_Vectors instead of Bounded_Vectors, Bounded_Maps (& Bounded_Strings?) still to do.
• Radiolink flashes the left red LED on transmit, the left green LED on receive.
• UART_Syslink implements flow control. Flashes the left red LED on receive overrun (note clash with Radiolink!), the right red LED when a DMA transfer has to be suspended for flow control.

[simonjwright]

Another part of the reason for the original problem (basiclog.py fails to report anything) is that Log calls CRTP_Is_Connected, which depends on whether the copter is receiving flight commands, & resets logging (deleting all blocks) if it isn’t; but in the equivalent C code, hal/src/radiolink.c:60 leaves the isConnected component unset, so crtpIsConnected at modules/src/crtp.c:219always returns true.

[AnthonyLeonardoGracio]

Hello Simon,

Thank you very much for investigating this! I will have a look at what you have done in your fork. Feel free to suggest a pull request when you want :)

[simonjwright]

Anthony,

Now see the logging branch (I’ve rebased).

I’ve managed to mix changes to get logging working with changes to use my cortex-gnat-rts, which makes it a bit difficult to make a simple pull request. If you decide you want the logging changes I’ll untangle them!

[AnthonyLeonardoGracio]

Hi Simon,

I would be great if you can untangle them indeed, we definitely want to integrate the work you have done regarding logging!