I have been a bit slow to get into the whole logbook thing, but in the bright side i do have a few things to say !
In the beggining of the week we tried to fix a few objective and specs for the project, we managed to agree on
- Having as much balloons as possible in order to have a “swarm” effect and ha them practice choreographies.
- Use a mothership (bigger baloon, with most likely a different micro-controller) in order to coordinate the smaller baloons.
- Keeping it useless.
Now these points have to be justified. My main idea (or vision) is one of a swarm of balloons, dancing in the air, with a lot of different light; its purpose would simply be to beautiful and distracting, other functions could be added (the first one that came to my mind was having them interact with the spectators, making circles around them or following them).
It seems really important to me not to force a more useful function because, let’s be honest, there are no use of a swarm of balloons (except keeping your children and ROSE students busy maybe …). By forcing a use on this project not only would we fail to achieve it properly, but we would also be likely to loose the magic and beauty that we could have had if we had simply kept the idea of a show.
Once we accept the fact that the balloons will be useless, we can now focus on how to make them rock at being beautiful and interactive (maybe). First I thought that being able to create choreography on a computer or android device, and then simply sending this information to the balloons and have the executing this choreography (moves plus light effects) would be amazing. Keeping in my this idea, the more balloons we could have, the more impressive this show would be, thus we had to keep them cheap. That’s where the mothership idea came from, if we could limit the amount of captors on our regular balloons, we could drastically lower their prices, and thus increasing the visual effect of the show/performance (plus, cheaper is always better), so having a central balloon sending the other balloons where to go (relatively to him) would allow us to limit ourselves to simply know the positions of the balloons relatively to the central balloon (=> almost no captors on them).
This chain of reasoning lead to our current technical issue : knowing the position of the balloons relatively to the “mothership”.
We choose not to be too picky on the precision of this position. As the balloons have to be at least 60cm/24′ large in order to float without external help (filled with Helium, it lifts about 100g/3.5oz) an error of about 10cm seems more than acceptable (about 10m/11yd of range for BLE, which will be the protocol used in message exchange), plus it should allow us to use cheaper captors (money, money, money).
At first I thought about using an infrared camera on the mothership and having an infrared in each balloon, the mains advantage is its low cost and ability to scale (IR LED would cost 5$ max), plus the STM32F4 [p.330] (which we are likely to use) already supports video, we yet have to find out if it is able to do all the calculation fast enough. But on the bright side, finding big balloons (which should be the only visible sources of infrared of this side) shouldn’t be that hard.
Meanwhile I also had to work on a presentation with Olivier on 6LoWPAN, Embedded TCP/IP and CoAP, we chose to split first and share our discovery afterwards, I worked on 6LoWPAN he worked on CoAP.
These researches allowed me to discover an amazing fact, some Wikipedia articles are longer than the RFC they are talking about, obviously i discovered this only after having read this article … As I had already used XBee modules on other project I was somewhat used to IEEE-802.15.4, so I found rather interesting to discover another implementation of this protocol than Zigbee.
I won’t go into the details of the research, nor the results, as you will be able to see them in tomorrow’s (or today’s depending on the timezone) presentations slides, and as you may already be bored of this rather long post.