

Can Airware be the operating system to connect the world's drones? - katm
http://www.wired.co.uk/magazine/archive/2015/07/features/airware-drones/viewall

======
andymoe
I don't think the operating system to connect the worlds drones is going to be
closed source. 3DR and their open source base is going to give Airware a run
for their money as the de facto standard "operating system for drones" in the
consumer and more and more in the commercial space.

In the meantime people like Drone Deploy and Skycatch will fill the gap when
it comes to data collection and processing which is where the real business is
long term. Drones themselves will continue to become a commodity. Also, it's
worth remembering that a Chinese company, DJI, has about 80Pct market share in
the US for consumer and prosumer drones. Lots of competition for everyone.

~~~
freeqaz
3DR's software doesn't compete in the commercial space. It's a hobbyist
platform and it will be much harder to certify by the FAA or other agencies.
That is a huge portion of being successful in the space. Especially when
you're doing things that have more risk, like photographing electrical
infrastructure in a densely populated region. The FAA is going to be the
agency that determines if you can do that, and the companies that has that
advantage will win the space.

~~~
kenrikm
There is no reason why it would be any more difficult to certify then Airware.
The 3DR stuff is already more then capable todo the task and 3DR sells in the
commercial space. Source: I've personally done multiple long range (many
miles) autonomous missions and landed within 3ft of the target landing zone, I
have hundreds of hours of flight time with many different platforms (Naze32,
APM, Pixhawk, DJI).

~~~
chatmasta
Maybe a stupid question, but how exactly do you "personally" do "autonomous"
missions? Isn't it a one-or-the-other sort of thing?

~~~
kenrikm
If drones could build themselves, program themselves charge themselves etc..
then maybe it would be one or the other. For the time being someone needs to
do those things so while it might be autonomous as far as flying goes there is
still much human interaction to be had.

------
Htsthbjig
I have more than 20 drones of different sizes, some of them are big.

I am never going to buy a drone that is not mine(closed source) when I could
buy machines that are totally under my control.

Being closed source means the NSA could easily snoop what I do at every
moment, in Europe, send the GPS coordinates, the telemetry, pictures and
videos all the time without my consent.

US companies are becoming increasingly spies of the US gobertment all around
the world, specially people that worked closely with Uncle Sam, like those
guys from Airware.

I don't see Chinese or European companies buying into this, when they can
tailor open source into their specific needs. We already do that, so it is not
that complex thing to do.

I see this article as PR.

------
amelius
It sounds like vaporware :)

~~~
sjtrny
It is just a pr piece.

~~~
evilolive
It is definitely PR. Airware has invested a lot more into doing its own
hardware, its own possibly certifiable low level code than doing exciting
things (sense & avoid etc). Heck, no amount of money will let you write a
single line of code on their OS for drones currently.

But is the PR going to work ? It seems easy enough to deter the "serious guys"
doing some "serious commercial inspection" from using 3dr. The same way people
use cisco equipment on their network because they're told that's what you do
if you want peace of mind.

------
stefanix
"That kind of stovepipe way of doing things isn't going to scale,"

It's amazing how many times this argument is made by proprietary systems
people. In their world the web should have never happened.

The only chance they have is to use lots of VC money on certification bs that
tries to lock out open source projects.

I smell PR as well.

------
slavik81
Good luck. There's so much diversity in the equipment, payloads and use cases
for these systems that it's incredibly difficult to standardize. Cutting
integration costs has been a dream for many years, but previous standards
introduced more complexity than they eliminated.

~~~
spc476
Go back to the late 70s/early 80s and marvel at the incredible diversity in
computers, most with unique operating systems.

Standardiztion will happen eventually.

~~~
slavik81
It's a good point that we've seen this before. I'm under the impression that
many early computer standards were essentially de facto standards caused by
everyone trying to be compatible with a market leader. e.g. "Unix-like" or
"IBM PC compatible". That's probably not the only way, though.

I guess the real question is "how are successful standards created?"

------
dharma1
nah. It will be ardupilot (or another open source flight controller) on linux,
and because it's on linux, you have access to all the other open source
goodies you need for processing, analytics, connectivity etc.

It's already happening - check out [http://emlid.com](http://emlid.com) or
[http://erlerobotics.com](http://erlerobotics.com) for boards you can use with
Rpi2 or Beaglebone Black

~~~
ericd
These look nice for consumer applications, but Big Enterprise Companies
typically aren't looking for something thrown together using a RPi, and some
of them are going to use a LOT of drones. The hobbyist market doesn't really
seem significant compared to the number that will be used by utility, mining,
telecom, and other companies with sprawling physical networks of assets.

~~~
ObviousScience
I'd still expect that we'll see something like a real time OS microkernel
written in hardened C or Ada/Spark or kin with a standard suite of drivers to
control sensors, motors, etc.

Most of those kind of things get written as open source projects, and then
compiled in to specific bundles by middle men who get certified by insurance
companies to reliably choose and compile such bundles.

Big companies (eg, Boeing) will naturally still just use the open source
microkernel tied together with a few in house drivers, since they have the
capacity to deal with software certification themselves.

Really, I wish hobbyist drones would start having more functional co-
processors, because I want one where the flight computer and the user land
computer... aren't the same core.

~~~
dharma1
normal linux kernel runs fine for realtime tasks when compiled with prempt rt
flag -
[https://wiki.dronecode.org/_media/elc01.dronecode_and_ardupi...](https://wiki.dronecode.org/_media/elc01.dronecode_and_ardupilot_-
_andrew_tridgell.pdf) and it's possible to do very intesive computation on the
computer running the flight controller - Andrew does a demo where he flies
while compiling the linux kernel on the same computer at the same time, no
glitches :)

And if you want a co-computer, it's quite easy - use any board you like, for
instance Nvidia Jetson which has tons of GPU cores for paraller processing,
and just talk to the flight controller via mavlink over ethernet

~~~
ObviousScience
> it's possible to do very intesive computation on the computer running the
> flight controller - Andrew does a demo where he flies while compiling the
> linux kernel on the same computer at the same time, no glitches

My point is that it's incredibly dangerous to build this as our default
security model in drones, because while it's certainly the case that the
flight controller has the raw processing power and if our security worked
perfectly, it wouldn't be a problem we live in the real world and errors in
userland execution shouldn't be able to break the control loop and send heavy
toppling down on your head.

Just because you're probably smart enough to do your taxes while you drive
doesn't mean it's not safer if you focused on the road.

> And if you want a co-computer, it's quite easy - use any board you like, for
> instance Nvidia Jetson which has tons of GPU cores for paraller processing,
> and just talk to the flight controller via mavlink over ethernet

Yes, I expect that the model we'll see for consumer drones is something like a
Kepler embedded module running userland, with a second, standalone ARM core
running the flight controller (with the flight controller exposed as a device
in userland, but talked to as a server on the wire).

Probably with some kind of hardened RTOS on the flight controller, and Linux
running userland OS.

This has the benefit that controlling the drone is no different than lots of
other devices we control, we can work in our usual operating system, and we
get to perform a sanity check between userland and flight control execution.

