This is a true application of technology
Low cost but the potential to help so many people, even if it's just with basic post-disaster mapping and sensor recordings. I wish them the very best of luck.
A British-led Japan-based group is building a free-software-powered flying robot for use by disaster relief organisations – and at its heart is tech darling the Raspberry Pi. There are lots of uses for the £30 Pi, from an educational device to a media player, if you can get hold of one of the boards. OpenRelief is planning …
Low cost but the potential to help so many people, even if it's just with basic post-disaster mapping and sensor recordings. I wish them the very best of luck.
Thanks Thomas! Our goal is to fill some of the gaps that were experienced during the Tohoku disaster situation in Japan, where normal recovery services were overwhelmed, and where we can make a real difference with relatively modest technology. If we can call a flying robot modest technology. Crazy times, eh?
More than that, can we help?
Absolutely everyone can help. Drop over to http://www.openrelief.org to see precisely what we are doing, and then join one of our mailing lists to contribute to development or outreach. :)
I wish I were much younger and much smarter. Maybe this will inspire the young and smart to create good stuff like this instead of going into finance.
Part of the reason the young and smart go into fields you consider evil is that they are highly remunerative. Playing with R/C toys to save the world, however enjoyable, doesn't seem too likely to fall in that category.
Thankfully there's more to life, and to feeling like you've led a fulfilling one, than the accumulation of money.
Trust me, we're not especially smart. But we are determined, and we have access to the collective work of a lot of smart people due to the nature of FOSS and Open Hardware. We are standing on the platforms of giants, so to say. Now we need more people to lend a hand, whether their experience is in wielding screwdrivers, coding on the back of cornflake packets, or financial management. All sorts of people are needed to help refine the type of broad solution platforms and sensors we are pulling together. Do feel free to drop into the developer and outreach lists someday.
Just to clarify, we are not playing and these are not RC toys but semi-autonomous robots. Kiddo, when you drive an SUV loaded down with aid into something like Tohoku and try to get triage doctors to the frontline, come back to me and talk about playing. We are donating time, energy and money to solve a problem that lead to people dying. Making money from this is not our motivation. It's that simple.
Remember the old saying:
"He who dies with most toys, wins!"
This fulfills that nicely :-)
Selling them as toys could also raise further funds for the project.
Indeed it could, and one of our goals is to foster an eco-system (yes, yes, I know...bear with me) of participants in our community. Think of OpenRelief as a design project where a lot of different people donate time and knowledge. This project is not going to be commercialized because we need it to remain as a neutral space for collaboration on the pure technology. However, to actually build and deploy that technology around the world we need companies using the designs to produce products.
These products will contain technologies that readily deployable when a disaster occurs and which will be easy to integrate with larger disaster management systems and processes. And you are correct. One way to seed the market with the technology is to address the hobby market. With our *retail* costs still hovering under 1,000 USD to build these machines, I think it's fair to say there would be interest. These robot planes are awesome cool.
For integration with other projects it might be useful if the drone and support equipment can be transported in the same design of container as used by ShelterBox.
You suggested that we try to use the same size box as ShelterBox, and that's not a bad idea. However, checking out the dimensions, I saw a note on www.squidoo.com that said "The standard Shelterbox weighs 110 lbs. and has approximate dimensions 33" x 24" x 24"." Their size is not ideal for our airframe, which has segments that run to about 1.2 meters. However, we will seek to use standard shipping sizes on the final recommended packaging, optimized for doing things like stacking in industry standard containers to maximize efficiency.
Just a note then to avoid this simple mistake: The doors on a standard ISO or US shipping container are slightly lower and sometimes even slightly narrower than the internal space of the container! AND also important, a pallet has to be lifted to get it out, so you cant have a pallet exactly as high as the door! (I've seen these mistakes at least 8 times so far even in big organisations that should know better) Keep this in mind and have some airspace above the boxes. This also helps with ventilation/circulation and slightly mitigates "container rain".
I wish you lot all the best in your endeavour. And I hope it can one day help to save some lives (although the best would be if it was never needed at all ofcourse)
http://www.shelterbox.org/about.php?page=9 and click on the box to get their dimensions, but that's about right. I think in the past I've seen double length boxes as well but they've switched toa Flash site which makes it harder to find.
Why is it El Reg seem to be unable to mention the raspberry Pi without getting in some snarky remark about being able to get hold of one. We all know that there were problems early on due to huge demand. We all know that the situation is improving. So give it a rest El Reg it's starting to wear thin.
We'll move to talking about broken USB and SD support instead.
Well at least that is a legitimate criticism.
"Both communicate with the Raspberry Pi over plain old Ethernet."
Because the USB is still flaky for a lot of people with quite ordinary devices (keyboards, mice, USB 3G sticks, etc).
and the SD cards are still having problems too.
Greg K-H mentioned to me at LinuxCon Japan that the Pi appears to have a polling issue on the USB, with up to 60% CPU taken if you are in that state. It's not really an issue for us when we do something like connect the camera to the Pi (it's just on all the time), but it's something to work through when the autopilot and the Pi are working together. Quite frankly this is an area where we would appreciate help.
The drone really does turn the "victims" into victims !
@ Lee Dowling. USB is only flakey because the pi cant supply the required voltage. Powered USB hub. most problems solved.
Unfortunately something similar was my first thought
"BBC Middle East bureau editor Paul Danahar, who visited Homs with a team of UN observers earlier on Monday, said the Syrian army appeared to be using an unmanned surveillance drone to select buildings as targets for shelling. "
Wrong. Read the post I wrote.
It acknowledges packets on the wire (electrically) and then loses them into the void somewhere inside the firmware. People have put USB logic analysers on the task and proven that the RPi hardware responds exactly as instructed, as if it had received the packet successfully - unfortunately, something in the firmware removes the packets before they hit userspace.
I *did* link the git issue reference for a specific reason, and that's people blaming "power" for EVERYTHING wrong with the RPI (I still have an SD card travelling half-way round the world to let Broadcom try to work out why it refuses to boot on the RPi but yet EVERYTHING else sees it fine - that wasn't power either).
P.S. I also use a mains-powered stabilised power supply. If the RPi is pulling 10A on its own with just a single USB device, we have bigger problems than USB!
Drawing 10A sounds like CMOS latch-up to me. But I don't know how to solve it.
I have an ardupilot / arduplane and I would have hoped to see more cred points to it in this article as - even though it is credited with "Control of the aircraft" .. it has built in accelerometers, magnometers, GPS autopilot, waypoint + altitude navigation, geofencing, fly-by-wire capability, telemetry etc etc ... it's an incredible piece of kit that can almost fit inside a matchbox ... at a squeeze... ok a swan vesta matchbox then. The Pi is just a passenger in all this (for what I can see) and does not actually direct the navigation (yet).
The Ardupilot is indeed insanely great. The amount of technology they have packed into that tiny bit of kit is astonishing. At the moment the flying bit is all done by the Ardupilot and the visual work is done by the Pi. We are now in a six month testing cycle, and during that we hope to proceed to the point where the Pi can "see" something and - according to mission instructions - make a decision. For example, it might see a person, and get closer to obtain better footage.
Anyway, you are quite correct. The flying bit is all about the Ardupilot loaded with the Arduplane mix. We discuss this in the technical slides on http://www.openrelief.org and, beyond that, we are awfully excited about the forthcoming second generation of the pilot, which will reduce the retail cost from circa 300 to 200 USD.
I know this is meant to be a civilian project. But I just can't get past the double meaning of "the green boxes mark out where the drone's software thinks a victim might be found". How long to we see a weaponised Raspi?
Matthew, it's extremely unlikely that you will see aggression on this sort of platform. It's an entirely different design goal to make a disaster relief or other civil technology to a military technology. While you could attempt a repurpose, it ends up being a bit like trying to use a car as a tank. If someone wants a military drone, they can get a basic one at low cost on Alibaba which is more suited to offensive work. See for example http://www.alibaba.com/product-gs/544231109/Hunter_UAV_Platform.html
Anyway, the key point is that this is not about the technology. It never is. Yes, a drone can spy on you or harm you. So can a tape recorder or a fork. What matters is the motivation of the person behind the tool. As it happens, with a little positive motivation we can do astonishing things to help people with this type of technology, and I think we should not undermine that with an assumption of inherent harm.
"Matthew, it's extremely unlikely that you will see aggression on this sort of platform. It's an entirely different design goal to make a disaster relief or other civil technology to a military technology. While you could attempt a repurpose, it ends up being a bit like trying to use a car as a tank."
If the plans are available for free, it becomes far more convenient to build the drone than it is to order a drone and have it shipped from China, or anywhere else pretty much. And all it takes is a block or two of C4 and a detonator to turn the drone into a useful weapon for terrorists:
"OpenRelief is publishing all its plans and code online – the source at Gitorious and schematics on Solderpad. The team is also working hard at documentation – it will not be selling the drones itself, but handing all the information to organisations so they can build their own at a planned cost of between $750 to $1000 per unit, depending on component choices."
Just program it to fly into an open-air market, for example, at the busiest time of day. Why it would be anything other than easy to repurpose the vehicle for such tasks is not clear to me.
I dunno... When I saw the boxes marking all the people behind the guy dressed in brown as victims, my first thought was "Amazing! It can even spot flatuence!"
Shane, with the greatest possible respect, have you ever had any dealings with US export controls and the people that run them?
You don't even have to be in the US or dealing with US-sourced product for the US to claim US export control rules apply.
Anyway, the point is that stuff which in their view potentially has a munitions use (like, er, cryptography, precision machine tools, and at one time even fast PCs, as well as more obvious stuff e.g. things that fly, take pictures, and potentially have a payload that goes bang) will likely be subject to "dual use" regulations. Not just the manufactured items, but the information on how to manufacture them.
The fact that there are much simpler and more cost effective ways of achieving the weapon-centric result (e.g. AliBaba) is neither here nor there as far as these people are concerned.
Or is this all already in hand and I'm just worrying too much?
Best of luck anyway.
You asked about US export controls. The first thing I would say is that such types of control can be a sticking point regarding practical deployment, but I would immediately follow that acknowledgement with a "don't worry, these matters are in hand."
Your statement that "You don't even have to be in the US or dealing with US-sourced product for the US to claim US export control rules apply" is not entirely accurate. The US jurisdiction ends at the US border. For deployment in - for example - Japan we need to worry about the equally strict but slightly different Japanese rules. And the same applies elsewhere. Indeed, it is a much more complex problem than US rules alone, and a substantial amount of time and thinking is spend on this matter.
That said, getting right back to your identified potential sticking block, it's important to remember that the US is a key potential market for this type of disaster technology, and we are purposefully designing OpenRelief tools to ensure that import and export regulations will be met. Indeed, we will work closely with government and non-govermental bodies doing UAV work in the USA to ensure we fit effectively into what they are doing. That process has already started.
So, valid point. Actually a bigger issue than US controls. But it's something we are purposefully addressing in the design and deployment of OpenRelief.
"The US jurisdiction ends at the US border"
You'd better not tell that to the many many UK workers who are told the exact opposite by their company's Export Control people. Not all of these companies are even subsidiaries of US companies; they may just be companies that want to sell into the USA, and in order to have any chance of doing so, are compelled to follow US rules.
I won't attempt to paint more of the picture here, but interested readers (?) can go read about extraterritoriality of (US) export controls.
Once again, best of luck. But watch your back.
Despite the inbuilt (kneejerk?) cynicism of some of the commentards, this is a wonderful project designed for nothing other than the benefit of our fellow man.
I don't have the technical smarts to contribute to it but is there an opportunity to help with funding?
Everyone can help OpenRelief, whether by actually helping with development and outreach, or by contributing resources. We are setting up a UK association to accept these donations and distribute them to developers to help obtain prototyping technology. If you visit www.openrelief.org and join our "user" mailing list, there will be a clear announcement when the association has a bank account and donation button.
And...thank you! I really appreciate the positive feedback and offers of help. :)
Just wait until the Daily Mail see this, terrorists can now get plans for a programmable guided missile for free off the internet !!!!! AAAAHHHHHHHH!!!!!!!
its not the daily mail you have to worry about - when MS realise this is a flying Kinect the legal battles will leave millions dead.
Just don't tell them about the Anarchist's Cookbook.
I'm sure plenty of people of obvious association, if not origin, just burning to get even for the predator havoc. Expect to see that flying machine banned in the UK soon, just as a precaution, of course. Imagine one of those, or a fleet of them, unleashed in central London against... no, I can't even bring myself to think such illegal thoughts
uh-uh, I can hear the black (drone) copters buzzi
Rather than waste weight with explosive, put a small tank of something extremely poisonous in, with outlet nozzles on the prop boss or in the prop wash somewhere. Then it could just cruise about over a crowd, killing/maiming a lot of people until it ran out of power or nasty stuff.
any of you open sourcers see code donations from a user called 'Skynet' for f**ks sake dont use it
The fact that the arduplane has to talk to the Pi over Ethernet points to a bit of a design flaw: the Pi does not have Arduino compatible GIO pins, and there is no miniport Linux driver for applications to talk to sensors.
The wonderful thing about Arduino is that the open-source design has built (over years) a rich ecosystem of sensors and controls that span smart-clothing to smart droids.. Raspberry Pi is neat, but it would have been better if it followed the netduino approach and tried to be a clever microcontroller before trying to be a cheap PC
God no, the Pi is still in nappies compared to Arduino and the scads of compatibles/competitors, if the demand/supply thing works out (and there's every sign it is doing) then expect a Pi with the same maturity as Arduino to be so much more than any of the current crop of hobbyist boards. There are already tutorials out there on talking to sensors for Pi
Raspberry Pi has GPIO pins, I2C, SPI and UART. And voltage level conversion isn't hard.
1. Depends on the Arduino, some are 5v some are 3.3v.
2. Drivers can be written.
3. The Pi is aimed at a different market to the Arduino.
4. The Arduino has been around for several years vs a couple of months on the market for the Pi. There is always a development curve and time is a big helper is this matter. Not to mention the Pi is a much more complex device than an Arduino.
I have one relatively trivial problem. There is talk of various sensors but no reference to a payload mount designed to be as universal as possible.
Our current sensors are canaries, so they are actually ground-based and can broadcast up to the robot plane to let it know what's happening. For example, the radiation detector can send an alert via the Internet or up to around 500 meters in the air if there is a dramatic rise in radiation. In the future we will have modular airplane sensors too, but that's a little down the line.
Any particular reason for the design to built into a plane and not a hovering device ?
Probably the same as with normal aircraft vs helicopters: range/ endurance, speed, simplicity & ruggedness.
Helicopters are very useful for staying in one place, or travelling very slowly, but are a poor cousin to a plane when the main aim is to cover ground.
For instance - finding open routes, unblocked roads, bridges that aren't collapsed etc. I would imagine to be a very useful aim.
For that to be done effectively I would imagine that covering a large area in a search pattern (or following a route until it fails the 'route is open' criteria and then mapping from the last branch) and determining the state of routes would be best undertaken by plane.
So if anyone at Google wants to spend some 20% time (or anyone else of course, but it would be easier with access to the google earth maps) to work on plotting A to B routes that are open then I'm sure there is some kudos to be had.
I must admit that this is a cool project, and I wish I had the time to spend on it. The uses just for disaster management are huge, let alone more commercial applications.
Biting the hand that feeds IT © 1998–2017