Start developing with Crazyflie 2.0

[alec]

Hi everybody,

My name in Alessandro, I'm an electronic engineering student, and I want to start developing with CrazyFlie2.0
I have some experience in C programming for microcontrollers, but I never used Python and any RTOS.

my equipment/tools:

- Crazyflie 2.0
- Crazyradio PA
- Loco Positioning deck
- Nodes (working with the same hardware technology of LP nodes, but with a different firmware, and different protocol)
- Eclipse C/C++

My goal is to adapt the nodes at my disposal, to Loco Positioning Deck.

First of all i would like to understand:

- what should I study before starting writing code.
- how does the crazyflie communicate with crazyradio and LPS nodes, and understand the software state machine behind the system.
- how can i set up a Tool-Chain for Eclipse, to compile the code (and maybe simulate it)
- Which part of the firmware(s) should i look to understand the communication between deck and nodes, and which part should I change for my purpose.

I apologize for inaccuracies, but i really don't know where to start.

I thank anyone who can provide some suggestions / documentation / support

[arnaud]

Hi, Welcome!

Thanks for the well-constructed post with clear question, makes it much easier to answer!

For the hardware side you have all you need.

- what should I study before starting writing code.

Getting familiar with the Crazyflie code architecture is a good idea. We have one documentation that takes you from nothing to changing an LED behaviour, it is a good way to get started: https://www.bitcraze.io/getting-started ... velopment/

- how does the crazyflie communicate with crazyradio and LPS nodes, and understand the software state machine behind the system.

Crazyradio and LPS nodes are handle in two completly different way.

Crazyradio is part of the CRTP communication stack, it is used to send CRTP packet back and forth with the Crazyflie. You can find some documentation about CRTP in the wiki: https://wiki.bitcraze.io/doc:crazyflie:crtp:index. Depending on what you are exactly interested into there is more documentation about the Crazyradio itsef, higher level protocol, and there is the code to understand how things are implemented (for instance there is an abstraction layer that allows us to use USB as well as Crazyradio easily, it is done so that other link could easily be added like serial port or even UWB radios).

The LPS communication is handled by the Locodeck deck driver. The doc about the deck drivers is in the wiki as well: https://wiki.bitcraze.io/doc:crazyflie: ... mware:deck. The deck driver is initialized automatically when the Loco deck is detected at startup and it initialize and uses the UWB radio.

- how can i set up a Tool-Chain for Eclipse, to compile the code (and maybe simulate it)

Setting up the toolchain is documented on github: https://github.com/bitcraze/crazyflie-f ... -toolchain

The Crazyflie project uses a simple Makefile to compile so Eclipse is not a hard requirement. If you want to use Eclipse you can start from the configuration we setup in the virtual machine: https://github.com/bitcraze/bitcraze-vm ... ject-files. In the virtual machine this folder is copied in the home folder and the projects are cloned in the projects/ folder (so that they end-up in the same folder as the eclipse configuration).

Unfortunately there is currently no way to simulate the Crazyflie code.

- Which part of the firmware(s) should i look to understand the communication between deck and nodes, and which part should I change for my purpose.

You should look at the locodeck.c file, this is the driver for the UWB chip. The ranging algorithms are in the files named lps...: https://github.com/bitcraze/crazyflie-f ... rivers/src. The code is architectured in such a way that it is easy to swap the ranging algorithms for another one, this is how we can compile TWR or TDoA mode. You can start from one of the existing algorithm or create your own.

There is some reference doc on the wiki about the TWR algorithm: https://wiki.bitcraze.io/doc:lps:lpp

I hope this helps you getting started, do not hesitate if you have more questions.

[alec]

Hi arnaud and thanks for your help.

I started understanding the way the code works, but i still have some doubts.

Where does the position estimation algorithm run? Does everything run on the drone, or some part of the comuputation is stil done on the PC?

I have a DecaWave EVB 1000, and a ST-LINK V2. Is there any way to flash the lps firmware with this devices? Do you think that there are any chance that this will work in some way?

Thank you again!!

[arnaud]

The position estimation runs in the kalman filter. See stabilizer.c for the main loop that runs state estimation and control algorithm. The kalman filter is run from this loop. The ranging algorithms are pushing data to the kalman filter (the data are pushed in queues and are used the next time the stabilization loop runs the kalman filter). Currently the kalman filter can work with distances (ie. TWR) and difference of distances (is. TDoA).

Since we are using the DWM1000 module, using an EVB will work for sure, though it will require some work to port the algorithm to the board. I see two approaches if you want to keep the crazyflie untouched:
- Porting the dwm-node firmware to the EVK board
- Re-implementing the anchor algorithm in the EVK firmware.

I have not worked with the EVB so I have no idea what solution is the best or the easiest. We have already ported the node code from another STM32 so if the EVK has an STM32 it should not be that hard to port.

If you want to keep the EVK firmware you already have and just make the Crazyflie compatible with it then you have to provide a new algorithm in the Crazyflie (the same way we can currently choose between TWR, TWR-TDMA and TDoA).

[alec]

Thaks again!!

But i still have a lot of issues going on, so I'll try to be more clear, explaining you my problems.
I followed the tutorial about toggling system led color from red to green and everything worked fine on Windows, through VM.

I'm currently involved in a project for an internship in my university, and my goal is to develop a complex demo with a Crazyflie 2.0, but I'm a beginner in this field.

I have a Carzyflie2.0 with loco deck, crazyflie radio (does ROS recognize crazyradio automatically?), an Xbox controller, a set of Decawave EVB1000 boards ( http://www.decawave.com/products/evk1000-evaluation-kit ) that i connect to my PC through an ST-LINK V2.

I'm running everything on Ubuntu 16.04, I've installed ROS, downloaded the virtual machine suggested on your Wiki ( and I still have some problems with the USB port cofiguration. The latest VM didn't work properly with the latest VirtualBox release, so i had to install the previous one, but nothing changed. on windows was ok).

Before touching the firmware, i would like to set up my work environment properly, and test the drone, like ( like you do in this video https://www.youtube.com/watch?v=ZgH4bLZdq2A )

I don't want to keep the EVK firmware, i prefer using yours, but i'm not sure about all the steps i need to follow to do this. is it possible to simply flash lps node firmware on the board I have? I don't know also how to set addresses for the drone and for the anchor.



P.S. I know, everything in this post is confused, and i have i lot of questions, ad it is also difficult to give me a precise answer.
but i'm looking for a starting point, and for now, it would be great just making ROS communicate with anchors and tag, and visualize it in the graphic interface
Thank you again!!!

[arnaud]

Hi,

thanks for the precision, I think my previous message still holds. Your basic problem is that you need to get the EVB and the Crazyflie to communicate together on UWB. My 3 solutions are 3 path towards that goal so you 'just' need to choose one .

Flashing the unmodified nodes firmware in the EVB will not work since it is not the same board. We configure the nodes using a serial port (either a USB serial port implemented by the firmware or a real serial port using an FTDI cable). This is documented in the wiki.

If you do not plan to keep the EVB firmware then you can start by porting the node firmware to the EVB. I think the EVB is using an stm32f103 (to be confirmed), if so the port should be quite straightforward since we are using the STM cube API which is quite similar between STM32 cpus (the first version of the nodes had an stm32f103 so the firmware is already designed to be ported, we tried to keep platform specific code in an "f0" folder).

[alec]

Hi Arnaud,

As far as I have understood, I can follow different paths:

1) Adapt the existing lps aglorithm to make it suits the EVK1000
2) Adapt the crazyflie firmware in order to let it communicate with the default EVK1000 firmware
3) Write a brand new one

But in this way i should also modify something in ROS? Or ROS doesnt see this changes?

As you can imagine, working for the first time with a real professional firmare, is not easy, so I'm trying to figure out how to tie up loose ends

Which part of lps firmware shoud I re-implement? in other words, where is, in your opinion, the boundary of abstraction provided by the RTOS? are there specific files you think i shoud modify? Does this change something with ROS/crazyradio?

If i decide to adapt crazyflie firmware to make it communcate with the default EVK1000 firmware, which part of the code should I modify? does this have some effects on other parts of the system? Will i have problems with ROS/crazyradio too?

[arnaud]

Hi,

The three solution I saw was:
1) Port the lps-node firmware to the EVK1000 hardware
2) Implement our LPS two way ranging in the existing EVK firmware
3) Implement the EVK two way ranging algorithm in the Crazyflie

The reason why I never talked about ROS is because it is independent. The two way ranging algorithm will produce a structure that contains position of the anchor, distance to the anchor. This information is pushed to the Kalman filter and used to estimate the Crazyflie position. What ROS is seeing is the estimated position and with ROS we can send position setpoint. This is independent of the ranging algorithm.

Which part of lps firmware shoud I re-implement? in other words, where is, in your opinion, the boundary of abstraction provided by the RTOS? are there specific files you think i shoud modify? Does this change something with ROS/crazyradio?

On Crazyflie and LPS Node firmwares, the ranging algorithms are reasonably separated from the rest of the firmware which makes them easy to modify and change. I would expect the Decawave code to be architectured in the same way.

If i decide to adapt crazyflie firmware to make it communcate with the default EVK1000 firmware, which part of the code should I modify? does this have some effects on other parts of the system? Will i have problems with ROS/crazyradio too?

On Crazyfle the UWB radio configuration is in locodeck.c: https://github.com/bitcraze/crazyflie-f ... locodeck.c
The two way ranging algorithm is there: https://github.com/bitcraze/crazyflie-f ... psTwrTag.c
If you want to make your own algorithm you need to make a structure with function pointer to connect it to locodeck.c: https://github.com/bitcraze/crazyflie-f ... .h#L77-L81 for example this is how the TWR is initializing it: https://github.com/bitcraze/crazyflie-f ... #L360-L363.

If you where to do your own algorithm, look in the existing one to see how the data are sent to the kalman filter.

The architecture is very similar in the nodes/anchors so you can easily isolate the code that does two way ranging if you want to port it in the decawave firmware.

[wenlong]

Hi, arnaud
You said that "The ranging algorithms are pushing data to the kalman filter (the data are pushed in queues and are used the next time the stabilization loop runs the kalman filter). Currently the kalman filter can work with distances (ie. TWR) and difference of distances (is. TDoA)."
I am not clear about this process, could you give me more detail about it? Thanks
Sincerely

[arnaud]

Hi wenlong,
I am not sure what details you are after. If you look at the EKF code you will find both the implementation and the papers this implementation is based on: https://github.com/bitcraze/crazyflie-f ... r_kalman.c