adacore / certyflie

Crazyflie 2.0 Firmware

This branch contains the source code for the full Ada + SPARK Crazyflie 2.0 firmware. If you want to use the SPARK + C version, switch to the crazyflie2 branch instead.

Folder description

./                       | Root, contains the .gpr project file
 + Ada_Drivers_Library   | As submodule
 + crazyflie_support     | Support library
 |  + src                | Supprt code
 |  + test               | Some test code
 + src                   | Application code

Git usage

This repository uses git submodules.

Clone with the --recursive flag to clone the submodules:

git clone --recursive https://github.com/AdaCore/Certyflie.git

To update, pull as normal, then update the submodules:

git pull
git submodule update --recursive

Requirements

The firmware is written in Ada 2012 and in SPARK 2014 and targets an STM32F4 chip, based on ARM. Therefore, a compiler for ARM (ELF) is needed: The "GNAT Community 2018" compiler for ARM (ELF) is one such compiler. A recent GNAT Pro compiler for that target will also suffice.

At this time, it's not possible to perform SPARK analysis (the 2016 version can't handle recent changes to Project files, and the 2017 version crashes).

Building the firmware

The firmware uses a Ravenscar-Full runtime that targets STM32F4 boards. This runtime is included in the "GNAT Community" for ARM (ELF) package and in the recent GNAT Pro packages for ARM.

To build the actual firmware, go on the project's root directory and type:

 gprbuild -P cf_ada_spark.gpr -p

Flashing the firmware

The firmware can be flashed using the STM32F4 DFU mode.

First, install the dfu-util on your matchine. On Ubuntu:

apt-get install dfu-util

Then,

1. Plug the USB to micro-USB cable into your laptop
2. Disconnect the battery from your Crazyflie 2.0
3. Push in the power button on your Crazyflie 2.0. While continuing to hold in the power button (this is the tricky part), plug the micro-USB connector end of the cable into the Crazyflie.
4. Continue holding the power button for about five seconds since you plugged the USB cable in). Watch the blue LED on the M2 arm until it displays a secondary (faster) blink rate (flashes about once a second). Then you can release the button.

With the STM32F4 in DFU mode, you should be able to find it with lsusb:

lsusb
...
Bus XXX Device XXX: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

Create the BIN file from the ELF one with objcopy and then flash it using dfu-util:

arm-eabi-objcopy obj/cflie.elf -O binary obj/cflie.bin

sudo dfu-util -d 0483:df11 -a 0 -s 0x08000000 -D obj/cflie.bin

certyflie's Issues

gprbuild error undefined attribute "runtime"

pi@raspberrypi:~/crazyflie/Certyflie $ gprbuild -P cf_ada_spark.gpr -p
cf_ada_spark.gpr:29:08: undefined attribute "runtime"
crazyflie_full.gpr:10:08: undefined attribute "runtime"
gprbuild: "cf_ada_spark.gpr" processing failed

Certyflie on Crazyflie 2.1 Device

I'm looking to use the Certyflie firmware on a Crazyflie 2.1 device. I have identified differences between the 2.0 and 2.1 hardware and firmware that may make the Certflie firmware incompatible with the 2.1 device. Additionally, I have flashed the Certyflie firmware on a 2.1 device and recorded my findings below.

First, they have different IMUs:

Crazyflie 2.1:

• 3 axis accelerometer/gyroscope (BMI088)
• high precision pressure sensor (BMP388)

Crazyflie 2.0:

• 3 axis gyro (MPU-9250)
• 3 axis accelerometer (MPU-9250)
• 3 axis magnetometer (MPU-9250)
• high precision pressure sensor (LPS25H

Next, there is a difference in the firmware source code:

The drivers in the 2.1 firmware source code suggests the Crazyflie 2.1 device is using an MPU-6050 vs the MPU-9250 in the 2.0 device. This is likely related to the differences in IMU hardware listed above.

I was able to build and flash the Certyflie firmware successfully onto a 2.1 device. After turning on the device, the LED state is as follows:
M1: Solid Red
M2: Solid Blue
M3: Slowly Blinking Blue
M4: Off

When attempting to connect to the device with the most recent build of the python client, I have observed two outcomes:

1. The client hangs while establishing a connection with the Crazyflie and never successfully connects. The M4 LED is solid green with constant red flashes intermittently.
2. The client successfully connects. the M4 LED is solid green with constant red flashes intermittently. No telemetry data from the device is shown in the client GUI and no commands from the client are reflected in the Crazyflie device.

M2 and M3 LEDs remain solid blue and blinking blue respectively. Interestingly, the M4 goes from solid red to off in both cases listed above.

The issues/concerns I have outlined are likely not exhaustive.

Are there plans of making this repo compatible with the 2.1 device? If not, any suggestions on how to achieve compatibility would be very welcomed.

gnatprove -P cf_ada_spark.gpr --ERROR

Hello,
We have this error, using spark on the ada-code of the Crazyflie:

:~/Documents/GT/Certyflie$ gnatprove -P cf_ada_spark.gpr --RTS=/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4 --mode=prove modules/pid.ads

warning: attribute "Target" of your project file is currently ignored by gnatprove
warning: to specify target properties, specify option "-gnateT" using "Builder.Global_Compilation_Switches"
Phase 1 of 2: generation of Global contracts ...
Phase 2 of 2: flow analysis and proof ...
safety.ads:16:16: medium: float overflow check might fail
safety.ads:18:16: medium: float overflow check might fail
safety.ads:56:21: medium: range check might fail
+===========================GNAT BUG DETECTED==============================+
| GPL 2017 (20170515) (spark) Program_Error why-gen-expr.adb:338 explicit raise|
| Error detected at imu.adb:119:32 |
| Please submit a bug report by email to [email protected]. |
| GAP members can alternatively use GNAT Tracker: |
| http://www.adacore.com/ section 'send a report'. |
| See gnatinfo.txt for full info on procedure for submitting bugs. |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact command that you entered. |
| Also include sources listed below. |
| Use plain ASCII or MIME attachment(s). |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/system.ads
/home/pierrecivit/Documents/GT/Certyflie/hal/imu.adb
/home/pierrecivit/Documents/GT/Certyflie/hal/imu.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/ada.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/a-numeri.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/a-reatim.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-osinte.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-multip.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bb.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbpara.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/interfac.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/i-stm32.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/i-stm32-rcc.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-stm32.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbbopa.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbmcpa.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/i-stm32-pwr.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-stoele.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbthre.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbcppr.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbtime.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbinte.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbbosu.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bbthqu.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-bcprmu.ads
/home/pierrecivit/Documents/GT/Certyflie/utils/filter.ads
/home/pierrecivit/Documents/GT/Certyflie/types/types.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/components/src/motion/mpu9250/mpu9250.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/hal/src/hal.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/hal/src/hal-i2c.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/hal/src/hal-time.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/a-nuelfu.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-gcmain.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-libsin.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-libpre.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/boards/crazyflie/src/stm32-board.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/devices/stm32f40x/stm32-device.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/dma/stm32-dma.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd-dma.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32-gpio.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd-gpio.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32-exti.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/hal/src/hal-gpio.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32-adc.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd-adc.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/uart_stm32f4/stm32-usarts.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/hal/src/hal-uart.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd-usart.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32-spi.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd-spi.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/hal/src/hal-spi.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32-i2s.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/hal/src/hal-audio.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32-timers.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32-dac.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd-dac.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/i2c_stm32f4/stm32-i2c.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd-i2c.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/stm32-rtc.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/hal/src/hal-real_time_clock.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/drivers/crc_stm32f4/stm32-crc.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f40x/stm32_svd-crc.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/components/src/motion/ak8963/ak8963.ads
/home/pierrecivit/Documents/GT/Certyflie/Ada_Drivers_Library/middleware/src/ravenscar-common/ravenscar_time.ads
/home/pierrecivit/Documents/GT/Certyflie/config/config.ads
/home/pierrecivit/Documents/GT/Certyflie/modules/console.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/a-sytaco.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-taskin.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/a-except.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-parame.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-stalib.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/a-unccon.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-traent.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-tasinf.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-taspri.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/a-taside.ads
/home/pierrecivit/Documents/GT/Certyflie/modules/crtp.ads
/home/pierrecivit/Documents/GT/Certyflie/lib/generic_queue.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-full-stm32f4/gnat/s-unstyp.ads

imu.ads:95:45: warning: no Global contract available for "Milliseconds"
imu.ads:95:45: warning: assuming "Milliseconds" has no effect on global items
imu.ads:99:57: warning: no Global contract available for "Milliseconds"
imu.ads:99:57: warning: assuming "Milliseconds" has no effect on global items
imu.ads:121:58: warning: no Global contract available for "Milliseconds"
imu.ads:121:58: warning: assuming "Milliseconds" has no effect on global items
compilation abandoned
gnatprove: error during flow analysis and proof

about my version of gnatprove :
:~/Documents/GT/Certyflie$ gnatprove --version
2017 (20170515)

Have you any suggestion ?
Thank you for your time.

Can’t build with GNAT GPL 2017

With both a Linux download and a macOS rebuild, we get (modulo line numbers)

$ gprbuild -p
using project file cf_ada_spark.gpr
Compile
   [Ada]          main.adb
a-stream.ads:65:09: expected type "Standard.Boolean"
a-stream.ads:65:09: found type "Ada.Tags.Size_Ptr"
a-stream.ads:65:09: expected type "Ada.Tags.Select_Specific_Data_Ptr"
a-stream.ads:65:09: found a composite type
a-stream.ads:65:09: no value supplied for component "Tags_Table"
gprbuild: *** compilation phase failed 

Same replacing the embedded-runtimes submodule with the latest commit.
Just building the RTS:

lockheed:ravenscar-stm32f407disco simon$ gprbuild -P ravenscar_build.gpr -XRTS=ravenscar-full
Compile
   [Asm_Cpp]      start-rom.s
   [Asm_Cpp]      start-ram.s
   [Asm_Cpp]      start-common.s
   [Asm_Cpp]      handler.s
   [C]            raise-gcc.c
/Users/simon/adacore/embedded-runtimes/base_runtimes/ravenscar-full/common/raise-gcc.c: In function 'exception_class_eq':
/Users/simon/adacore/embedded-runtimes/base_runtimes/ravenscar-full/common/raise-gcc.c:869:10: warning: implicit declaration of function 'memcmp' [-Wimplicit-function-declaration]
   return memcmp (except->common.exception_class, ec, 8) == 0;
          ^~~~~~
   [C]            adaint-xi.c
   [Ada]          s-lisisq.adb
   [Ada]          s-lidosq.adb
  ...
   [Ada]          s-string.adb
   [Ada]          s-strhas.adb
   [Ada]          s-stratt.adb
a-stream.ads:65:09: expected type "Standard.Boolean"
a-stream.ads:65:09: found type "Ada.Tags.Size_Ptr"
a-stream.ads:65:09: expected type "Ada.Tags.Select_Specific_Data_Ptr"
a-stream.ads:65:09: found a composite type
a-stream.ads:65:09: no value supplied for component "Tags_Table"
gprbuild: *** compilation phase failed

Executable loads over CF bootloader

The Crazyflie memory map has the bootloader at 0x08000000 and the main firmware at 0x08004000, whereas Certyflie loads at 0x08000000, thus overwriting the bootloader and preventing over-the-air updates.
I’m not sure how this could be easily corrected; the load address is fixed at low level in the runtime, so at first glance we’d need a new runtime. Perhaps the loader script could be parameterised.

Migration to embedded-stm32f4 run time

Hello,
Would it be possible for you to migrate the code to the more recent run-time 'embedded-stm32f4' rather than using the old ' ravenscar-full-stm32f4'?

I am facing quite a few issues:

Thanks.

Definition of axes

I’ve been using the SensFusion code as a basis for the equivalent in AdaPilot, and I think at least part of my problem is the definition of the axes used (not helped by the fact that the MPU9250 chip is differently oriented on the Crazyflie 2.0 board w.r.t. the AdaRacer board).

I’m pretty sure, from reading how IMU handles the data from the chip, that SensFusion’s coordinates are:

X positive Forward
Y positive Port
Z positive Up

and it’d be great if this could be written in the code - for example, in the types IMU.Gyroscope_Data, Accelerometer_Data, Magnetometer_Data, and also perhaps in the other modules that use the data - Stabilizer, and SensFusion6(which doesn’t actually use the record types, but which has parameters *X, *Y, *Z).

Note, there appears to be much confusion about coordinate systems; equally if not more valid would be the body-centred equivalent of North-East-Down, i.e.

X positive Forward
Y positive Starboard
Z positive Down

Mistranslation in Madgwick algorithm

In modules/madgwick/sensfusion6.adb:367,

S1 := Q1_X4 * Q2_Q2 - Q3_X2 * Norm_Ax + 4.0 * Q0_Q0 * Q1 -
  Q0_X2 * Norm_Ay - Q1_X4 + Q1_X8 * Q1_Q1 +
    Q1_X8 * Q2_Q2 + Q1_X4 * Norm_Az;

appears to be a mistranslation of the C code from http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/, at MadgwickAHRS.c:

s1 = _4q1 * q3q3 - _2q3 * ax + 4.0f * q0q0 * q1 - _2q0 * ay - _4q1 + _8q1 * q1q1 + _8q1 * q2q2 + _4q1 * az;

(the second term should be Q3_Q3, not Q2_Q2).

(The Ada is clearly a translation of the referenced C code, since - aside from using the identical algorithms - the spelling errors in the original C appear in the Ada, e.g. "decent" for "descent").

Building Issue (GPL 2017): a-stream.ads:65:09: expected type "Standard.Boolean

Hi, I downloaded the last version of Certyflie and tied to build it using GNAT GPL 2017 ARM ELF with the recommended line " gprbuild -P cf_ada_spark.gpr -p ".
I'm getting this errors:
`
...
main.adb:54:11: (style) incorrect line terminator
main.adb:55:10: (style) incorrect line terminator
a-stream.ads:65:09: expected type "Standard.Boolean"
a-stream.ads:65:09: found type "Ada.Tags.Size_Ptr"
a-stream.ads:65:09: expected type "Ada.Tags.Select_Specific_Data_Ptr"
a-stream.ads:65:09: found a composite type
a-stream.ads:65:09: no value supplied for component "Tags_Table"
gprbuild: *** compilation phase failed
[2017-06-26 11:06:21] process exited with status 4, 0% (1/530), elapsed time: 00.78s

´

Can someone see what I'm missing?

I did not installed SPARK Discovery from AdaCore if that helps.

Thanks for any help!!.

Compilation problem : "Interfaces.Stm32.Rcc" is not a predefined library unit

Hi,

I'm trying to compile the ravenscar-cf-stable branch on commit a71ba52

lambret@debian-sogilis:~/CAP2018/Certyflie$ gprbuild -P cf_ada_spark.gpr -p
arm-eabi-gcc -c -gnatQ -gnatyg -O0 -gnata -gnatwae -g main.adb
main.adb:30:06: "Interfaces.Stm32.Rcc" is not a predefined library unit
main.adb:30:06: "System.Bb.Parameters (spec)" depends on "Interfaces.Stm32.Rcc (spec)"
main.adb:30:06: "System.Bb.Parameters (spec)" depends on "System.Stm32 (spec)"
main.adb:30:06: "System.Stm32 (spec)" depends on "Interfaces.Bit_Types (spec)"
main.adb:30:06: "Main (body)" depends on "Ada.Real_Time (spec)"
main.adb:30:06: "Ada.Real_Time (spec)" depends on "System.Os_Interface (spec)"
main.adb:30:06: "System.Os_Interface (spec)" depends on "System.Multiprocessors (spec)"
main.adb:30:06: "System.Multiprocessors (spec)" depends on "System.Bb.Parameters (spec)"
main.adb:30:06: "System.Bb.Parameters (spec)" depends on "System.Bb.Mcu_Parameters (spec)"
main.adb:30:06: "System.Bb.Mcu_Parameters (spec)" depends on "Interfaces.Stm32.Pwr (spec)"
s-stm32.ads:32:25: "Interfaces" is undefined (more references follow)
gprbuild: *** compilation phase failed

I'm using gnat pro 7.4.2 :

lambret@debian-sogilis:~/CAP2018/Certyflie/Ada_Drivers_Library$ arm-eabi-gnat --version
GNAT Pro 7.4.2 (20160527-49)

I havent' find references to Interfaces.Stm32.Rcc but I find something close : the files s-stmrcc.ads defines a package System.STM32F4.RCC that we can expect to implement such interface.

My guess is you're using an more up-to-date toolchain but I dont exclude an configuration problem on my side :)

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

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.

gprbuild error

Hello everyone,

I have an error when I try to build the firmware :

:~/Documents/GT/Certyflie$ gprbuild -P cf_ada_spark.gpr -p
cf_ada_spark.gpr:26:08: undefined attribute "create_missing_dirs"
cf_ada_spark.gpr:30:08: undefined attribute "runtime"
crazyflie_full.gpr:16:08: undefined attribute "runtime"
crazyflie_full.gpr:18:26: unknown attribute "runtime"
config.gpr:19:09: variable "target" is not typed
config.gpr:20:12: illegal case label "riscv32-unknown-elf"
stm32f40x.gpr:11:08: undefined attribute "create_missing_dirs"
HAL.gpr:11:08: undefined attribute "create_missing_dirs"
cortex_m4f.gpr:15:08: undefined attribute "create_missing_dirs"
components.gpr:14:08: undefined attribute "create_missing_dirs"
middleware.gpr:18:08: undefined attribute "create_missing_dirs"
ravenscar_support.gpr:13:08: undefined attribute "create_missing_dirs"
gprbuild: "cf_ada_spark.gpr" processing failed

I guess, I have correctly installed the compiler for ARM (I went on http://libre.adacore.com/download/configurations, selected both the platform "ARM ELF Format" and the platform "x86-64 GNU Linux (64 bits)", downloaded all the linked files and then installed the GNAT GPL 2017 for the 2 platforms, following the given instructions)

Here is what is in my file :

:~/Documents/GT/Certyflie$ ls
Ada_Drivers_Library cf_ada_spark.gpr config drivers gnat.adc hal init lib LICENSE.txt modules README.md types utils

Have you an idea ?

Thank you

Problem with Ada tasking on the Crazyflie

There appears to be a problem in the runtime with tasking. This occurs on the Crazyflie after running fine for a couple of minutes. For some reason all tasks simply stop running without any reason (no exceptions are raised either). This causes the Crazyflie to really act to its name and flies like crazy because the main thread that calls the stabilizer_control_loop also stops.

I checked this by adding a small task that does nothing else but toggle a LED. The blinking of this LED eventually stops, but the LEDs for system and battery animations keep going. These LEDs use the Ada.Real_Time.Timing_Events and are not affected.

To investigate the problem I have turned off (commented out) functionality until I reached a point where the tasks no longer stop (or get blocked).
When I comment out in uart_syslink.adb:UART_Syslink_Init the call to 'Enable_USART_Rx_Interrupts', the problem seems to have disappeared.

The compiler I use is GNAT GPL 2016 for Linux, running on the bitcraze VM (Ubuntu).