This page describes the first online live Bitcraze tutorial session were we have explained the lighthouse spiraling swarm demo we have been showing and multiple conferences in the last few years. Here we will mostly focus on the lighthouse positioning system, high level commander and the App layer.
Registration is closed
Tutorial information
Here you will find the information about the tutorial itself.
Schedule
Date: 4th of November 2020
Start time: 18:00 CET (Malmö Sweden)
Place: Online on Discord and Mozilla hubs
Schedule:
- 17:45 - 18:00: Walk in (especially for Mozilla hubs)
- 18:00 - 18:35: Tutorial part 1 - Lighthouse positioning
- 18:35 - 18:45: Questions
- 18:45 - 19:00: Break
- 19:00 - 19:35: Tutorial part 2 - Swarm Autonomy
- 19:35 - 19:45: Questions
- 19:45 - - - - - : Socializing
Topics
For the tutorial we will assume that you already know the Crazyflie and have done some development for it in some way, so the introduction to our ecosystem will be very brief.
There are two main parts of the tutorial:
- Lighthouse v2. We will explain how to setup the lighthouse v2 with the theory of how it works, and eventually fly with it with one crazyflie.
- Swarm Autonomy. Here we will explain communication with the swarm and how to move more autonomy into the Crazyflie (very important for flying with swarms). High-level commander and the App layer will be explained here. After this the full demo can be shown.
Location
- Starting point: On the day of the event we will send you an email with an invite to our_Discord_ server, which is the virtual starting portal to our tutorial. So make sure that you have a discord account already.
- Discord: In Discord, there will be one channel for the video stream of the tutorial, and one channel for chat and question.
- Mozilla hubs: In the discord channel for chat there also be the link to the mozilla hubs room.
- Limitation: There is no limitation on how many people can join the streaming discord channel. There is going to be a limit on how many people can join mozilla hubs. We will reduce this to 20-30 people due to of the environment getting slow. We will indicate how the progress is going during the event but everybody who already indicated that they will join mozilla hubs have priority obviously.
Socializing
During the break and after the tutorial we can answer questions that are still remaining. We would prefer if they could be limited to the topics that we cover in the tutorial to also give us Bitcrazers some time to socialize with you guys in either mozilla hubs or discord :) That is something that we also really miss from not going to conferences so we are looking forward to meeting you all!
Slides and Presentation
After the event, we will post the slides we used here and a link to the recordings of the tutorial.
- The slides of the event can be found here
Questions and Answers
What are the main differences bitween the Loco positioning and the Lighthouse?
- Loco positioning is using UWB and Lighthouse laser sweeps https://www.bitcraze.io/documentation/system/positioning/
You said V2 doesn’t use all the calibration values (yet). Does it mean you can get a better accuracy with V1 for the moment?
- I don’t have any numbers for accuracy for V1 and V2, but they are probably fairly similar. The geometry of V2 makes it more sensitive to errors though
How much space can we cover compared to V1?
- Lighthouse is not limited to 2 base stations (as opposed to V1)
Could you please provide some links for v1 calibration
- Lighthouse V1 calibration https://github.com/bitcraze/crazyflie-firmware/blob/master/src/utils/src/lighthouse/lighthouse_calibration.c#L126-L136. We have not yet documented how to read/write calib data yet, but it can be done from the app layer in the Crazyflie.
What is the functional range of lighthouse ?
- The range of a lighthouse 2 base station is 5-6 meters
Are the settings from the app persistent?
- The settings are not persisted in memory, but since the app is flashed to the Crazyflie, and runs at startup, the settings will be set everytime it starts.
Can you estimate how many crazyfly can be used with one radio?
- The number of Crazyflies that can be used with one radio depends on how much data that have to be transmitted. More data / Crazyflie == fewer Crazyflies / radio. It is hard to give exact numbers but if you use a lot of logging and sending data the number will probably be less than 5. In Crazyswarm (with heavy optimization of cummunication) they handle 16 Crazyflies / radio
HL commander doesnt need position data from the computer? once it does its thing?
- In this example the HL commander uses a trajectory that is uploaded by the script. When started it continuously calculates set points for the controller based on that trajectory. Obviously the Crazyflie must know where it is for this to work, but pretty much any positioning system works but we use Lighthouse today
So it checks position in a few intervals instead of constantly?
- The trajectory is defined as a number of polynomials for position, velocity, acceleration and jerk
So it needs less control data.. but does get position?
- Yes, so setpotins are calculated all the time. It is also possible to use go_to commands in the high level commander. In this scenario it creates a trajectory from the current position to the destination that is then traced.
Is it possible to run this code without wireless charger?
- You would have to modify it slightly since there is a check in the state machine to make sure it charges after landing, but apart from that it should work
Have you tried continuously running this demo in a loop in order to find how long it could be repeated automatically?
- We have used this demo on ICRA and IROS and were pretty much running it 8 hours/day. We had to pick up a crashed CF from time to time but it runs really well!
In HL commander there would maybe be room for a crash-preventer?
- We have discussed running something like this as a part of our CI server to make sure the firmware actually can fly after a commit, but have not got around to do it yet. Yes it would be nice with crash prevention, but it assumes accurate positioning. Sometimes the positioning system adds errors and this is hard to handle
Demo
This section describes the demo we are running at tutorial with links to required source code to reproduce it.
We wanted to create a demo that is as fully automated as possible. We have 8 Crazyflie 2.1 with Lighthouse and Qi charger decks, each with a charging pad. A computer will orchestrate the Crazyflies and make sure one is flying at all times while the others re-charge their batteries on their pads. After a pre-programmed trajectory is finished or when the battery of the flying Crazyflie is depleted it goes back to its pad while another one takes over.
We use a computer for orchestration (we call it the Control tower) that controls when the Crazyflies take off. The communication between the computer and the Crazyflies is handled by a Crazyradio. When a Crazyflie has started, it runs its trajectory a fixed number of times or until it is low on battery. Basic state data is continuously transmitted from the quadrotors to the Control tower.
The Crazyflie firmware
The Crazyflies are fairly automated and are mainly controlled by simple commands from the control tower. The demo app implements a state machine where most state transitions are automatic, while a few require input from the control tower.
Initialization
When a Crazyflie is booted, it performs the normal initialization tests and waits for the positioning system to find its position. When it has position lock it is ready for action.
Taking off
When it is time to fly, the control tower asks a Crazyflie to take off. At this point the Crazyflie records its current position (for landing purposes), takes off and hovers above the charging pad. It is now ready to fly.
Flying
The Control tower sends a start signal to the Crazyflie which then goes to the first coordinate of the pre-programmed trajectory. When at the starting point it runs the pre-programmed trajectory, a set number of times.
Out of battery and landing
When the trajectory has been repeated the set number of times, the battery is low, or if the Control tower sends a landing command, the Crazyflie finishes the current trajectory and when it reaches the end, it uses the coordinate that was recorded at lake off, to find its way home. It hovers above the charging pad a few seconds to stabilize the position before it lands.
When landed it verifies that it is on the charging pad and that the battery is actually charging. If not, it will take off again and repeat the landing procedure.
Crash detection
The Situation awareness sub system is used to detect if the Crazyflie has crashed. If this is the case, the motors are stopped and the state machine is moved to a permanent crash state, awaiting human help.
The trajectory
The trajectory is pre-programed and hard coded in the app. It is handled by the High level commander that uses the Mellinger controller for control.
The trajectory is designed as a downwards spiral with a return path up in the center. It makes it possible to fly multiple (at least up to 4) Crazyflies at the same time at different phases of the trajectory, without colliding or getting into the down wash of another quadrotor.
The timing of the trajectory is good enough to start multiple Crazyflies and keep them running without any further adjustments.
The control tower
The Control tower is responsible for starting Crazyflies at the correct moment. In normal operation one Crazyfly is flying all the time and with 7 Crazyflies charging it is possible to maintain continuous operation.
It is possible to run the Control tower with more than one quadrotor active simultaneously, when it tries to slot them in equally spaced in the trajectory. It (sort of) works with up to 4 Crazyflies at the same time, but the risk of failure increases with the number of copters (which makes it more fun!).
There is also a synchronous mode where multiple Crazyflies are started side by side to fly the trajectory in parallel. This mode does not support live replacements when the batteries are out though.
Implementation
The Control tower is implemented in python using the Crazyflie python lib. It is based on a main control loop that evaluates the current situation in every iteration and takes appropriate action based on the state of the available quadrotors.
Each Crazyflie is monitored and controlled by a Controller that runs in its own thread. The most basic functionality is to keep the connection with the Crazyflie alive and reconnect when needed. When connected, logging is set up for the current state in the remote state machine, battery level as well as the current progress in the trajectory. The Controllers also have functions for sending commands to the Crazyflies.
The main loop queries the Controllers of the current state to determine if any action is needed. Basically it checks if the correct number of Crazyflies are flying. If not it will prepare the required number of Crazyflies by sending the take off command and eventually slot them in the flight pattern at the appropriate time. Only Crazyflies with a charged battery are taken into consideration for flight.
The control tower does not store an internal state, other than what it receives from the Crazyflies through the logging sub system. This makes it very robust and it can be restarted at any time without any further implications. This is also true for the Crazyflies that can be restarted at any time.
Products used in the demo
The following products were used in the demo, they are available for purchase in our store.
The Crazyflie 2.1
The Crazyflie 2.1 is a small, flexible quadrotor, suitable for research and education. The small size and light weight makes it safe and robust if crashing, while the open source software opens up the possibility to modify or examine any part of the functionality.
The Lighthouse positioning system
The Lighthouse Positioning System is based on the Valve Lighthouse base stations, used in the HTC Vive Virtual Reality gaming kit. It has very high precision and accuracy to an affordable price, making it possible to use in any office or class room. The position is estimated in the Crazyflie quadrotor which makes the system robust and easy to use.
The Qi 1.2 wireless charging deck
The Qi 1.2 wireless charging deck uses the same standard as mobile phones which makes it easy to find a compatible charger.
The Crazyradio PA
The Crazyradio PA is a USB dongle radio that is used to communicate with the Crazyflie. It supports up to 800 packets/s to multiple Crazyflies simultaneously.
The charging pad
The charging pads are based on the wireless charger “NORDMÄRKE” from IKEA with a 3D-printed pad. The FreeCad and stl files for the pad are available on GitHub in Landing_pad_rallen_v5.fcstd and Landing_pad_v5.stl.
The source code
The source code for the demo is available on GitHub under the folder example/demo/swarm_demo. Most of the functionality in the firmware is implemented in app.c and the Control tower is implemented in control_tower.py.
More information and how to setup the lighthouse positioning system.