FireSwarm

FireSwarm is officieel geëindigd, hoewel er nog steeds aan gewerkt wordt aan een vlucht met meerdere vliegtuigen. Dit kost voornamelijk veel uren test vliegen, wat pas mogelijk was nadat alle hard- en software klaar was. De datum van de demo zal tijdig worden aangekondigd.

Ook is er met Herman Kuijt (commandant brandweer Bergen) een afsluitend evaluatiegesprek geweest. Tijdens het gesprek bleek dat er verschillende praktische zaken zijn waar rekening mee gehouden moet worden voor toekomstige ontwikkelingen; hier volgt een verslag.

Ten eerste is het belangrijk dat de publieke opinie in de gaten wordt gehouden: het oorspronkelijke plan was om in de Duinen van Bergen enkele testvluchten te houden, maar dit werd een hachelijke zaak toen de inwoners van Bergen zich ernstige zorgen begonnen te maken over hun veiligheid en privacy. Dit leidde er uiteindelijk toe dat de testvluchten elders gehouden zijn; zowel technisch als demonstratief een gemiste kans!

Dit hangt ook samen met de wetgeving op het gebied van onbemande vliegtuigen. Op dit moment kan FireSwarm niet binnen de Nederlandse wetgeving gebruikt worden, omdat ieder vliegtuigje, hoe klein en ongevaarlijk ook, een piloot nodig zou hebben. Dit is voor de brandweer natuurlijk niet te doen: juist een systeem dat de snelle respons van de brandweer kan bevorderen moet zo veel mogelijk zelfstandig zijn werk doen. Ouderwetse wetgeving is dus zeker een probleem voor het vermarkten van dit onderzoek en er zijn slechts twee opties: wachten op verandering van de wetgeving (dit gaat helaas niet gebeuren op korte termijn) of uitwijken naar het buitenland.

Toch heeft FireSwarm veel potentie. Vooral een oplossing waarbij iedere kazerne één vliegtuigje op het dak heeft staan ziet dhr Kuijt wel zitten. In dat geval kan de brandweerwagen namelijk op pad gaan terwijl de vliegtuigen autonoom gelanceerd kunnen worden (of eventueel door een achterblijver op de kazerne). Binnen enkele minuten zijn de vliegtuigen dan in het gebied van ongeveer 3 bij 3 kilometer waar de brand is gemeld en kan de zoektocht beginnen.

Aangezien de brand tegen die tijd meestal al aardig groot en heet is en er meestal zelfs een rookpluim te zien is, zou de FireSwarm de haard snel opgespoord hebben. Met een beetje geluk zelfs binnen 10 minuten van de melding, zodat de brandweerlieden nog onderweg zjin en ze hun route naar de brand kunnen bepalen. Ook een luchtfoto kan veel helpen: aan de hand van zo’n foto kunnen ze een goede inschatting maken van de grootte van de brand.

Zeker als een luchtfoto beschikbaar is, is het niet heel belangrijk dat de informatie van het systeem altijd correct is: het is niet zo erg om pas bij de tweede plek waar je naartoe rijdt de brand te vinden. Aan de andere kant moet de echte brand natuurlijk absoluut niet compleet over het hoofd gezien worden!

Na het vinden van de brand en het beschikbaar maken van luchtfoto’s kunnen de vliegtuigen landen. De brandweer kan de vliegtuigen dan na het blussen gewoon oppikken en weer klaarmaken voor gebruik. Dat mag wat tijd kosten, het is immers gebruikelijk dat brandweerlieden na bluswerk nog enkele dagen bezig zijn om alle hulpmiddelen weer in orde te brengen.

Kortom, FireSwarm kan een mooie toevoeging zijn aan de machines de nu al gebruikt worden voor de brandbestrijding. Daarvoor moeten nog wel enkele obstakels overwonnen worden, en dan met name de wettelijke. Tenslotte is het belangrijkste aspect van FireSwarm dat het bijna geen moeite kost om het in geval van brand te gebruiken en zo heel snel de kritische informatie geeft de de brandweer nodig heeft.

Het verslag van het project: D1.1.1 D1.2.1 D1.3.1 D1.4.1 D2.1.1 D2.2.1 D2.3.1 D2.4.1

Testing the radio

The mission of the UAVs is to find a fire in an area. This leads to the problem of covering an area as fast as possible. An optimal path for each UAV could be calculated in advance, such plans however are not very flexible. UAVs cannot follow planned paths perfectly and there is no room for rechecking a possible fire. An interesting method is to use potential fields, resulting in a landscape where the UAVs are repelled by hills and attracted by valleys. As the landscape changes over time, the path planner keeps updating the plan. This method enables us to incorporate various other influences in the plan.

• Coverage: Repellers are placed on places that UAVs already observed, so that those places are not visited again.
• Collision avoidance: Repellers are placed on future path of UAVs, so that UAVs won’t fly in the way of other UAVs.
• Edges: Repellers are placed on the edges, so that the UAVs won’t leave the allowed area.
• Fires: Attractors are placed on possible fires, so that the UAVs can recheck to be sure. Once rechecked the attractor can be removed.
• Battery: An Attractor can be placed at the base when the battery is low, so that the UAV is ready to land.
• Connectivity: Either attractors or repellers can be placed to keep all UAVs and the base connected.

Simple simulations are used to get statistics about coverage. For these simulations, the flight dynamics, radio transmission and other things are simplified. Simulations with the software that will be on the UAVs are performed to check the simple simulations and to see how collision avoidance and landing works out. With this software we can also perform hardware in the loop simulations, so that timing becomes visible. A later blog post will reveal more details about the software. In this video, all UAVs fly at a different height, so collision avoidance will not be observed. It should be possible for the operator to call all UAVs back at the same time, while the UAVs cannot all land at the same time. By a simple queue system, each UAV will wait for lower flying UAVs in queue to land first. In this video, the landing is made visible by a sudden turn towards the ground station, which in reality will be a landing performed by the auto pilot.

May 22 we had a second sensor test flight. With this flight, we could test the improved payload modules and this time we did get usable images from the downwards facing camera. With these images we could try out some visual fire detection algorithms.

Color
The first algorithm simply filters by color.

Fire detected by color at the edges of the fire. The center is so bright that the pixels are over saturated (white).

Fire detected by color at the top center (few pixels at the helicopter). The yellow truck (down left) is also marked as fire and thus a false positive.

The color filter will result in many false positives and we will never be able to trust on color alone.

Flicker
The second algorithm tries to find flickering pixels: pixel values that go up and down over time. The camera recorded images in bursts of 8 images, here is such a burst of a very small fire:

Burst of 8 images of a small fire (at the helicopter), click to see the animation.

When we check for flicker and threshold the results, we get:

Flicker detection found the fire, but also many false positives.

The flicker detection also has many false positives. This is possibly caused by the motion of the plane, resulting in movement of pixels over the image. The moved pixel can be replaced by a pixel that has very different values. If this happens more often over the burst, it will be seen as a flickering pixel.

Optic flow
To be able to compensate for the movement, we need to calculate the optic flow. We followed the algorithm as described in Real-Time Quantized Optical Flow. This resulted in very noisy flow fields, which was caused by lack of texture in certain parts of the images. We filtered out those flow vectors by checking the difference of the possible displacements. If the difference is large enough, we assumed one displacement matched a lot better than the others and thus there must be enough texture. The result is shown in the image below.

Calculated optical flow of a big fire (click to see the animation).
Top left: original image
Top center: textureness
Top right: optic flow
Bottom: optic flow drawn as arrows

There is still some noise in the flow vectors, especially if the exposure time of the camera suddenly changes. However, once the exposure is under control, the noise will be low enough to use the optic flow to compensate and maybe even find moving smoke or fire.

Motion compensation
In the images below you can see results when we compensated for average motion.

Image burst compensated for average motion. Click to see animation.

Color and flicker detection on images compensated for motion. This removes a lot of noise for the flicker detection. Click to see the animation.

There are still more features that we can extract from the images, so far the results are promising and we trust that we can detect fire with the color camera.

A swarm of UAVs has to find one or more fires in a dune area by processing the images taken with the cameras directed downwards on the UAVs. It is a legal requirement that during flight, the UAVs keep a communication link with the ground station. This can either be a direct link or an indirect link through hopping. When a UAV turns or changes its altitude, the camera directed downwards shall have a limited view of the area beneath. Therefore, the amount of pitch and roll changes should by minimised.

In literature, many methods were found that handle similar problems. Here follows a  selection of the most interesting ones:

• Levy flight: flying randomly but with varying time steps

• Reynolds Boids / Potential fields: through attraction and repulsion between UAVs, several different behaviours can be established, e.g. swarming or formation flight.

• Pheromones: Using markings in the environment to guide robots, e.g. ant algorithms.

• Frontier-based: robots look for the frontier between known and unknown space and decide where the trade-off between the cost of going there and the amount of expected new information is best.

In order to test these pattern formation and swarming algorithms for the swarm of UAVs, the Paparazzi simulator is used. Paparazzi is an open source autopilot, see the Paparazzi Wiki. It includes the hardware and software for the autonomous aircraft as well as the complete ground station mission planning and monitoring software.
Here you see an example of the behaviour of 10 UAVs when simulated with Levy flight combined with a repulsive force between UAVs. In this example no communication restrictions were used. The square is the area to be covered and spans 5 by 5 km.

In Paparazzi, the easiest way to program the flight schedule for the individual UAVs is to set way points for each UAV. Then, each autopilot lays down the route to a way point. The carrots are the direction indicators of the UAVs.

The tested algorithms shall be assessed using the following function:

Where F is the function to be minimized,
t is the flight time in which the swarm has covered 90% of the area,
N is the number of UAVs,
Dcomm is a discount for having no communication link,
Wcomm is a weight factor,
Dturn is a discount for large pitch and roll,
Wturn is a weight factor.

To test the camera that will be on board the UAV, we lit up a barbecue in the garden of Almende and took some pictures. This was a good opportunity to tweak camera settings, test startup scripts and of course: see how well we can recognize fire.

The box you see on the picture will also be the box that is going up in the air for the sensor test flight. In that box the breakout board (Summit) will be replaced by a board made by Salland Electronics, on which more sensors will be connected (a thermopile array, a 3M pixel camera and a gas sensor).

In order to simulate the movement of the plane, the camera was rotating constantly from left to right by a simple construction of lego.

This was a nice test to see how sensitive the camera is for hot objects. When you combine a picture taken with an IR pass filter and a picture taken with an IR block filter, you can already distinguish the barbecue.

With these sample images we can already test out some fire detection algorithms.

In maart wordt de eerste testvlucht gehouden. Bij deze test gaan we kijken hoe goed de verschillende sensoren zijn in het herkennen van vuur. Daarvoor worden er verschillende objecten geplaatst zoals een auto met draaiende motor, een barbecue en een open vuur. Met deze objecten kunnen we onderzoeken hoe goed het onderscheidend vermogen is van de sensoren.

We zullen de volgende sensoren gaan testen:

• Normale camera (met een IR block filter)
• NIR camera (camera met een IR pass filter)
• Thermopile array (zoals in een thermal imaging camera, maar dan met weinig pixels)
• PIR (zoals in een bewegingssensor, zeer goedkoop)
• Microgolf sensor (zend microgolven uit en vangt de weerkaatsing weer op)
• Gas sensor (bijvoorbeeld koolstofmonoxide)
• Rook sensor

De vlucht zal waarschijnlijk uitgevoerd worden met de EasyStar. Bij de vlucht zal de UAV op verschillende hoogtes vliegen, om ook een idee te krijgen van de invloed van de hoogte op de vuurherkenning.

Maandag 31 oktober 2011. De spannende start van dit uitdagende project om een zwerm van onbemande vliegtuigjes de lucht in te krijgen en ze een gemelde brand zo snel mogelijk op te laten sporen. De vliegtuigjes moeten intelligent genoeg zijn om dit zelf te kunnen doen. Een brandweerman beelden te laten zien van een hele vloot van vliegtuigjes is ondoenlijk! We willen zelfs niet dat de brandweerman naar een langzaam opgebouwde luchtfoto aan het staren is. Nee, het idee is als volgt. De brandweerman heeft controle over de vliegtuig zwerm. Hij/zij definiëert een gebied waar binnen de vliegtuigjes moeten blijven. Ook heeft de brandweerman controle over het terugsturen van de vliegtuigjes. De vliegtuigjes doen met hun eigen sensoren een “quick scan” voor mogelijke vuurhaarden. Voor geografische plekken met een hoge vuurhaardwaarschijnlijkheid, moet er verificatie optreden. Ten eerste, de vliegtuigjes vliegen in een zwerm; een vliegtuigje dat op lagere hoogte vliegt kan de gedane observatie verifiëren of falsificeren. Ten tweede, de betreffende plek kan worden gecontroleerd door middel van complexere beeldverwerking gebruik makend van meerdere vliegtuigjes. Ten derde, foto’s kunnen worden genomen en de brandweerman kan op de hoogte worden gesteld van de “ontdekte” vuurhaard.

De verschillende partners binnen het project benadrukken verschillende aspecten. Het MAVlab van TUDelft, met het wereldrecord van het kleinst vliegende robotje met camera (de DelFly micro) van 3 gram: het moet zo licht mogelijk zijn. Salland Electronics, met bijvoorbeeld sensoren in stoelen om iemands houding te meten die net zo lang mee gaan als de stoel (10 jaar): het moet zo energiezuinig mogelijk zijn. Almende B.V., onderzoek en commercialisatie van grootschalige systemen (honderden tot miljoenen individuen) door middel van zelf-organisatie: ze moeten minder dan 1000 euro stuks zijn. Groningen, onderzoek doende naar grootschalige systemen in de biologie, zwermen van vogels: het moet zwermgedrag vertonen. Het mooie van deze diverse aspecten is dat ze perfect samenkomen. Hoe lichter – hoe energiezuiniger – hoe goedkoper – hoe meer…

De volgende plenaire vergadering is op 30 november. De beslissingen vallen over de zogenaamde “payload”, alle sensoren die aan boord gaan van de onbemande vliegtuigjes. Natuurlijk, als u uw producten, bijvoorbeeld een goedkope infraroodsensor, wilt testen in deze uitdagende omgeving kunt u vliegensvlug contact met ons opnemen. Wij zijn altijd geïnteresseerd in goedkope sensoren, aangezien we ze hopen uiteindelijk in groten getale te gaan afnemen!