BUG Community

Peter and I got back from FOSDEM a few days ago...wow what a weekend!  I gave a talk in the embedded devroom [slides] about BUG and OTE and then an hour later gave a lightning talk [slides].  Attendence was great and I got a lot of good questions.  We ended up giving out a total of 10 BUGs to conference attendees.  Two were reserved for a contest announced in the embedded dev room for people to mail me thier ideas for BUG apps and modules.  We got over thirty good responses, and we were up late into the night sorting through them and trying to determine the top two.  It wasn't easy!  In the end we ended up choosing two submissions that are somewhat related.  What made the difference in the end was the detail each put into the idea and the usability and practicality of such a solution.

The first idea from Py involves the classic "someone stole my [xxx] now I want to get it back" use case, which I first pondered after my bike was stolen right out in front of the office a few years back.  In this case, the object in question is a motor vehicle:

 Let's call it MoVeReSys, which stands for "Modular Vehicle Recovery System". Nowadays, all cars are factory fitted with alarms and various noise making systems, which most of the time prove very ineffective: nobody even turns head when a car alarm gets off. And when your car is gone, well, it is gone, and its too late. So speed of reaction is crucial to maximize chances of recovering your car. Also, knowing where your car actually _is_ can prove quite err... helpful in such a situation! ;-)

So, here is the minimal setup required: BUG base system, plus one GPS module, and one GSM module. Before moving the vehicle, you have to "authorize it" by pressing one of the BUG's buttons, or the system will start sending out its current position every minute or so, using sms, or pushing it to a webservice, or whatever you may want. Getting this information live on your smartphone, it is quite easy to interface it with google maps, to allow easy tracking of the vehicule in real time. With this sytem, you can be informed that your vehicle has been stolen within seconds of the actual theft! Jump in a police car and your car may soon be yours again! Obviously, this is the very minimalistic setup to build such a device. There are several possibilities to improve upon this design: 1) Having to press a dedicated button each time you want to start your car is a hassle, needless to say that one day or another you are going to forget it, and the system will "go live". And more importantly, it prevents the system from being completely hidden (which is much desired to keep a possible intruder to mess with it or simply throw it through the window...) Possible solutions: -Add an RFID module, and have an RFID tag in your pocket, so the system is always aware of your presence once you are close/inside the vehicle. -Add a bluetooth dongle: the system will detect your cellphone, in a similar manner to the RFID tag. -Add a BUGvonHipple module, hard wired to some of the vehicle controls. So you still have to do something to "unlock" the system, but you can much better hide the whole setup. A possible action could be to activate the rear windscreen wiper twice. It is also a desirable solution if several peoples are using the vehicle (its easier to tell a friend to do this or that than to program its bluetooth mac address in the system, or give him an RFID tag which he'll loose or forget somewhere). 2) In some areas, GPS coverage may not be available (inside under-buildings parkings, in urban area with lots of huge skyscrapers, ...). It is anyway much desirable to know _asap_ that the vehicle made an unauthorized move. GPS position will be sent out as soon as satellites are re-acquired. Solution: -You already know it: add an accelerometer module! Plus as a bonus, if your are paranoid, you can use the presence detector to let the system figure out there's an intrusion even before the car has started to move... It makes keeping the system completely hidden more difficult, but not impossible (eg detect the driver's legs from under the dashboard). 3) Without additional hardware, the software can be configured to keep a complete log of the vehicule's moves on the local storage. There is a ton of reasons you could like to have this information available: compute usage statistics for your vehicle, track a possibly cheating wife, ensure your mechanic is not using your car while it is supposed to just service it, or just some kind of plain log-everything-I-do-in-my-life-mania! 4) Having to physically chase the car with the cops, or trying to recover it yourself from the thefts can sometimes prove difficult, impossible or/and very dangerous. A better solution would be to have the theft abandon the car (and run away for its freeedom). Solution: -Add a BUGvonHipple module, again judiciously hard wired to the car, which would allow to shut the engine down remotely. Or more precisely, tell the system (per SMS) to stop the car at the next best opportunity (eg next time it is slower than 10mph). Such a system would be needed as I'm not sure stopping the engine when the car is doing 100mph on the freeway is a good idea, except if your goal is to trash it (have a good insurance policy?? ;-)), and try to kill that theft by the way... 5) You could also add a camera module pointing at the drivers face (ok, it makes things even harder to hide...), so you can have a live stream of what is going on in your vehicle, or (more realistically) "simply" keep evidence of the face of that theft, for the police.... or your heavily body-builded friends next door to pay him a visit ;-) 6) Another software enhancement, if you easily forget things, or find yourself like "damn, where did I park that car last night before entering that pub for the Fosdem beer event which gave me that first class hangover??". Well, send your car an SMS! And she will kindly come to the rescue of your poor brain... The possibilities are endless... And the fact that the BUG plateform make this readily possible is simply amazing! And I LOVE the fact it can be programmed in java using eclipse, it looks so nice to use and program! By the way, the integrated battery is a must! Let's say the thefts load your car on a truck, and disconnect the main car's battery to ensure the anti-theft system is not making nasty tricks in their back (like sending out the current car's position...). Well, no problem at all for the BUG plateform! It has its own integrated UPS! ;-)

Julien's app (the second winner) is interesting in that it converts unusual data into a spacial representation: vibration and sound.  I wonder the best way of visualizing these kinds of maps?  Of course with Bug Labs being filled with cyclists, it was hard to pass this up as a winner:

I've called it "Peacefull ride". The story is this one: I live in Brussels, Belgium. I ride a bike for ecological and practical reasons. (Statistically, if your trip is under 5km, a bike is the fastest ride. Faster than cars, tram, metro or any other transportation system). But, riding a bike can be sometimes stressfull  (not to my muscle though ;-) ). So here is the thing I would build with the BUG: I would use the GPS, Sound and Accelerometer modules. - GPS, is for tracking location (obviously ;-) ) - Sound module is for tracking "noise" volume. - Accelerometer is for tracking "bumps". (Yes, if I fix the BUG to the bike, everytime I'll be riding on paveroad, the BUG will know it.) How would this all work?: I would attach the BUG and all this modules to my bike and ride around Brussels and record all the data that it catches. The point is I want to make a map of Brussels that will record a number of variables important for bike riders and that is: How "noisy" is the road? Noise comes from traffic, mainly. Traffic is "bad" for bikes. It's stessfull. How "Bumpy" is the road? Again, bumps are bad for bikers. It slows you down, hurts your butt and hurts your bike too. And GPS? Well, it's to know where all those noise and bumps are and also to record how fast I was going. So to sum it all. After a couple rides accross Brussels, I'll soon have a map (thanks openstreetmap) of data showing me where I was the fastest, where it was the less noisiest and where the road was less bumpy. So then I could decide which way is the best to keep my bike ride safe and as stressless as possible. That's my idea. And I think this might be implemeted right away with your well promising BUG. Here's how I could extend it also: Add an "air pollution meter" + a "Heart beat detector" to track health data along the way and add it to my map.

All-in-all FOSDEM was a great trip and I hope to be able to attend again in the future.  I only wish they would space out the sessions a bit, as I got the feeling that I missed more than I wanted to, since everything is happening all at the same time.  Oh, and if you are lucky enough to attend FOSDEM at some point in the future, remember the BEER is STRONG.  Really strong, so pace yourself during the beer event!  I was not the only one fighting a hangover during my session.  Don't tell the boss.

Next week Matt, Mehrshad, and I are off to SCaLE in LA for more BUG fun (Oddly there are 3 concurrent sessions with "bug" in the title).  There are loads of people I'm looking forward to seeing there, people that were probably also at FOSDEM but due to the crazyness I was unable to find. 

• contest
• fosdem
• BUG
• scale
• conference