
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 …
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?
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.
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.
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.
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)
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.
"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).
https://github.com/raspberrypi/firmware/issues/19
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=97244#p97244
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.
Unfortunately something similar was my first thought
http://www.bbc.co.uk/news/world-middle-east-18398146
"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!
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.
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.
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.
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. :)
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.
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
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.
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.
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.
I keep saying we are a "design project," though actually we are a design and advocacy project. We are creating and refining these solutions, but a large part of what we are doing now and what we will do in the future is explaining how and why these solutions are a good idea. We believe this type of technology plays a very important role in societies around the world, and we want to help ensure that decision-makers are aware of why this is so.
Did you consider all the certification constraints for autonomous/semi autonomous light UAV systems?
I had to take a look at the Stanag 4703 a few monthes ago, and it's quite beefy.
It's a military standard (as the now ubiquitous DO-178B used to be) but I doubt the civilian regulations will be more lenient...
Here is an interesting but dated article on the subject:
http://www.uavm.com/uavregulatory/airworthinesscertification.html
Certification is an issue and it is something we are aware of. The short version is that in this rapid prototyping phase we are using kit that falls under the same experimental rules as high end RC, and we are taking care regarding the autopilot testing to make sure we don't cross lines. Down the road, when it comes towards the production ready-design and people moving into deployment, you can expect roughly the same types of requirement that microlights and similar aircraft receive. We will try to ensure that our design meet these requirements out-of-the-box.
However...
We are aware that regulations are currently trailing technology, and our focus is getting the technology ready to save lives. We won't hobble the engineering or the potential of this equipment because of rules in one jurisdiction or another. If we push up against a certification regulation that would potentially cost lives, we are going to engineer to save those lives, and we are going to approach policy-makers and advocate for change.
Hi Shane,
Great work. There are some great open source projects out there, but when people start bridging them together, some spectacular things emerge.
Here in Australia, there is a science TV program called Catalyst that has had some interesting stories in the past on UAV's, such as Honey Bee Aerobatics (http://www.abc.net.au/catalyst/stories/3318902.htm) , UAVs navigate with insect-like vision (http://www.abc.net.au/science/articles/2011/12/14/3390667.htm) and also the annual UAV Search and Rescue Challenge (http://www.uavoutbackchallenge.com.au/) first reported here http://www.abc.net.au/catalyst/stories/2836783.htm.
Now if you can bring some of these people into the project contributors, if they haven't already found you, the possibilities.
We are aware of the UAV Search and Rescue Challenge and already have one team member who wants to contribute to that event and share knowledge. The others are news to me, so thanks for bringing them to my attention! :)
I think you made a good point when you said that bridging tools and projects can produce great things. For example, no one part of OpenRelief is that interesting in itself, but seen as a whole we are heading towards a pretty cool solution to frontline disaster outreach. That happens because of the mix, and that mix happens because we can use, study, share and improve all of these technologies.
It's an exciting time to be involved in technology.
"It acknowledges packets on the wire (electrically) and then loses them into the void somewhere inside the firmware. "
Would that be firmware that is closed source by any chance? Either way, I find it strange that such a project has seen fit to accept the provision of closed source blobs.