Posts by shanecoughlan 18 publicly visible posts • joined 12 Jun 2012
My goodness! I missed you in Bilbao. The conference center was a bit of a maze. Hope to catch you at another event.
Package manager religion always fascinated me. It reminds me of the aspect of the photography world (a hobby) where people count metrics.
Most stuff is good enough to get us to where we want to go: something running. It strikes me that we should be caring mostly about “using the running” rather than arguing the startup.
That said, application images are my favorite too. As Liam probably recalls, I was wondering 20 years ago why something like ROX could not gain traction.
And mea culpa: my package management on OpenGEM varied from bad to horrific.
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.
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.
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.
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.
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. :)
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.
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 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.
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.
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 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.
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?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
