At Bitcraze we often get into discussions about crazy ideas that we would like to test out. Most of them are just that, crazy ideas, that are hard to realize or that we never have time for and the discussion ends (and a new one begins). But one of these discussions have been popping up time and time again, the idea of a flying sensor array based on the Crazyflie. Imagine a situation where you would need to distribute a large number of sensors over an area that you don’t have access to. You could also imagine a situation where you would like the measurement points to move over time. In these cases manually placing sensors at different points might not be a feasible solution.
During the initial design of the new Crazyflie we tried coming up with different use-cases for the new platform. We are not designing a “end-user” product that is intended for a specific end-use, instead we are designing a platform that is aimed at giving us and other users as much flexibility as possible to define the end-use themselves. But we still needed something to aim for, to try out our design on, and see if it could be done. One of these use-cases ended up being a flying sensor node. This might seem like a very specific usage, but we thought that if we come up with a design that would fulfill our basic idea and also a few far fetched ideas, then we would have something good. Hopefully this will be the case :-)
But we don’t only want to use the sensor array as a use-case, we want to build it! But as always time is in short supply. What’s the second best thing after doing something yourself? Seeing someone else do it! So we thought that this would be a great opportunity for a master thesis, where there would be room for both a theoretical part and a practical implementation part. Therefore we are hosting a thesis together with the consultant-company DevPort and the faculty of engineering at Lund University this fall semester. The theoretical part of the thesis includes investigating mesh-algorithms that could be used for a flying sensor array to relay commands to the nodes and to relay back sensor data. The goal is not to relay direct control commands though the mesh, but instead relay target positions for sensors or area that the array should cover. The goal of the practical part of the thesis is to implement basic functionality of the selected design using our new Crazyflie. The radio used in our new design is the nRF51822 from Nordic Semiconductor, we will go into more detail on the new radio in upcoming posts. We realize that this is a huge task, but we will do our best to help out. Between the three of us we cover mesh, radio, embedded systems and of course lots of knowledge about of the new Crazyflie and the nRF51822.
The thesis will be based on location in Lund/Malmö in Sweden, but we will of course share the progress and results on our blog. If this sounds like something that is interesting and you are looking for a thesis, then check out the description here (PDF here). Contact information for questions and applications can be found in the description.
So how did using this use-case when designing the Crazyflie effect the result? Well, one thing is that one of the pins in the expansion connector can be used for charging and powering the system. Think solar-cell, inductive charging or any other alternative source of power. It also sparked lots of discussions that effected the complexity of the power-management system, something that is now handled by the new radio MCU.
2 comments on “Crazyflie 2.0 based Master thesis for flying meshed sensor array”
Nice project! Is there a way to measure the link quality between two radios? Last time I checked this was done in the current UI by simply counting the number of dropped packets (OBSERVE_TX register). However, that requires to exchange a lot of data in order to get a reasonable measure. There is also the Received Power Detector (RPD) register, but that seems to have a binary treshold only.
I wonder if there are better ways doing that (possibly with additional hardware)? This would improve routing (and therefore latency) in the mesh.
The nRF51822 does actually have an RSSI measurement that gives the received power of a packet. Its between -40 and -100dBm and has a pretty bad precision (as usual for this king of measurement) but it is good enough to detect if a link is strong or about to be lost.