Canada says if a drone has a "remote" it's not autonomous. What would Chappie think?

Another clever legal post from Diana Marina Cooper, a lawyer doing some smart writing on the frontiers of robot regulation. FWIW, Canada seems to have confused "autonomous" with "optionally autonomous", which is actually what most modern drones are (they have both fly-by-wire and autonomous modes). From RoboHub:

Chappie, the new robo-film on the block, takes place in Johannesburg, where the police force is made up of robots. In one of the early scenes, the main characters, Die Antwoord’s Ninja and Yolandi take part in a drug deal that is raided by robot cops. Hoping to avoid a similar fate in their next deal, Yolandi suggests that they find the robots’ remote so that they can switch them off like TV sets. Do the robots have a remote? And do Ninja and Yolandi find it? No spoilers here, but let’s take up the underlying question in the context of drone regulations…

What is Canada’s position on autonomous and automated operations? Does your drone have a ‘remote’? If it does, according to Transport Canada, it is not an autonomous drone. Transport Canada defines an autonomous drone as one that does “not allow pilot intervention in the management of the flight.” It is not enough for an autonomous drone to be capable of self-governance, rather it must not allow for any possibility of human intervention.

What about drones that have a remote but can complete automated tasks such as take-offs or landings or that can execute pre-defined waypoint operations? Transport Canada distinguishes these drones from autonomous drones by pointing to the fact that they require operator initiation or intervention.

Although there is no express prohibition, truly autonomous operations are outside of the scope of Canada’s current regulations. For the time being, if your drone doesn’t have a remote, you wouldn’t be able to operate. Our framework permits operations that involve automation, but it requires that an operator have the capability to intervene – or rather, as Ninja and Yolandi would hope – your flying robot must have a remote.

Views: 1350

Comment by Gary Mortimer on March 17, 2015 at 9:29pm

Optionally piloted (OPV) is the phrase that comes to mind, good that Canada is thinking about these things. Quite cool seeing the little RSA flag on Chappie.

Comment by JB on March 17, 2015 at 10:01pm

The question I suppose is if having a remote in any way makes for safer use of drones.

The issue with any "remote control" is that the operator is not in the vehicle which typically leads to a certain neglect of responsibilities in their operation, because they feel safe in the belief that an incident will only harm the machine and not themselves or others. On the other hand a person in-the-machine does not suffer from such delusions and is acutely aware of the risks posed to his person should the intended operation of the tool fail. It is crucial that operators are made aware of the risks both prior and in real time to avoid and reduce the occurrence of any "incidences".

Typically most incidents arising from drone use start with user error, be that in the construction, setup or mission planning and operation of the drone. There is only so much risk that can be automated out of user control, especially with the extent of custom airframes being built without some sort of standardization. Also the user's limited situational awareness is not always such that user intervention is beneficial.

I think safe operation should be mandated by a) educating users on safe procedures b) limiting the impact of an incident by reducing size of the vehicle c) adding carefully considered automation protocols to control the remaining risks and functions that are best left up to autopilots...most of the time.

One thing that has  made general aviation safer is the implementation of checklists to avoid operational and maintenance/construction errors. Ardupilot/copter would benefit from a integrated checklist to at least highlight potential operation risks both pre-flight and in real time flight. Enhancing situational awareness without producing an informational overload is critical. The information must be actionable.

Like every man made tool, they can be used or abused. Educating the un-intiatiated of the limitations and intended function of a tool goes a long way to manage the safety risk and is a long accepted form of control that has been used in industry for decades.

Further I think the definition of "autonomous" in this situation is faulty. Every autonomous action any machine will ever make will always remain a direct or indirect response to the input of a human being. I haven't seen a system yet that has it's own consciousnesses or will. Or has someone made Skynet already and didn't tell me about it?

The ultimate responsibility of the operation of any tool will always be with humans. I'm sure Chappie would agree. ;-)

Comment by Gary Mortimer on March 17, 2015 at 11:32pm

There are checklists in the tablet GCS. Having a primary (critical control RC TX) and secondary (tablet to monitor operations and direct autonomous stuff) is going IMHO to remain a sensible way of doing business for some time to come. If I were a regulator I would not allow a system to fly that could loose link because an OTG cable becomes unplugged.

Comment by JB on March 18, 2015 at 1:28am

Hey Gary.

I'm aware of the checklists in the tablet GCS, they were in the original Droidplanner 2 already. However these are still limited and hard for the user to customize. There are some cool developments here: however I'd like to see a more interactive, both preemptive and realtime approach being implemented into the UI, that promotes safe use by establishing good pilot behavior and not just a checklist buried somewhere in the menu. BTW this is not meant to sound like criticism, rather a way to possibly improve consumer drone safety and ensure its survival beyond regulation.

Communication to and from drones is a considerable operational risk. Unplugging the OTG cable to your tab is only relevant if you use direct radio comms not IP or mesh based ones that have the ability to re-route. It's been a while since a plugged in a RFD900/HopeRF modules for comms on a tab or PC. 3G/4G is way easier and typically has nearly unlimited range in 95% of locations. Reliability for telemetry is on par or better than direct radio. Automated RTL on radio loss etc are functions already there to be used, but aren't significantly adopted because failsafes and geofences are cumbersome, in particular for newbies to setup.

The same applies for RC with low battery or range issues. Maintaining situational awareness whilst juggling RC and tablet, along with imaging duties etc is another thing that compounds the problem of safe operation. The majority of risk is when the consumer is learning operation of the equipment. We need the equivalent of "L Plates" for first adopters. This is where experience comes into play.

The reality of drone use is that a lot of people are entering this space with no to little operational experience, not even any RC experience (unlike us who were doing RC before anyone even dreamed of doing UAV). My point is that giving someone who is incompetent at flying an RC remote is akin to giving a gorilla a machine gun. No amount of calling him "Sir" will make it safe. RC overide IMHO offers only marginal reduced risk, particularly in a failure event where the operator is completely overwhelmed with decisions without a clue on how to respond. I think this is where some automation can assist. Flying mixed modes, that is both auto and manual/stabilise has it's own issues because the pilot isn't in the vehicle, and things like depth perception or aircraft orientation, particularly at range, typically lead to more "hard landings" than a "loiter" or "loiter at preset altitude" (for fixed wings) in auto would have, and would likely have been avoided completely if the user hadn't used the RC.

Similar to a airline "crashing" and the pilots going through emergency checklists instead of panicking, a drone user should only be given the choice to respond with appropriate actions, by limiting the action of the response to pre-defined parameters like "fly home", "loiter" or "land now". Along with warnings on battery range, comms performance or even local weather conditions etc it is possible to predict and pre-determine drone behavior and reduce risk. I think this belongs in the mix to make consumer drone use(r) safe.

There are just to many cascading system/operator failures that can lead to an incident that are exceptionally hard for a consumer to quantify whilst experiencing a "failure" event. I think the key to add this functionality is making the drone more "aware" of it's operational envelope by making it, for lack of a better term "Smart". For this the drone needs to become partially autonomous in it's decision making and will mean that we need to cut the tether to proprietary radio comms and finally make them IP based. This is so that the "intelligence" (or information and processing of relevant data) of the internet can be leveraged to not only increase safety but also add functionality, maintenance and interaction. In fact the next step is to make the drones an extension of the network to provide wireless service where they are currently not available (self deployed mesh network), and also communicate and interact with other airspace users. OTA updates of flight zones/no fly zones etc depending on pubic safety, weather, air traffic and privacy will be inevitable if we want to safely manage our airspace resource.

Essentially drone operation should follow similar principles to that used for radio transmissions by the FCC: To not produce interference to other users and to be unaffected (in it's safe operation) by other users.

I suppose in a sense Skynet is part of the solution. ;-)



Comment by Gary Mortimer on March 18, 2015 at 5:34am

I watched a chap with a brand new Iris (the first I have seen in the flesh) flying at a polo field last week just down the road from me. He had bought it in America, flown back to South Africa, charged it up and had a go. He said it was his fifth flight and I thought he did very well. I tried to say very little as it was his toy but when he sent it off on an auto mission that went at least 300m away and put down both smart phone and RC I had to say something.

The phone link was shouting lost connection which is was not worried about and I wondered how long it would be before the TX started complaining.

He had not heard of DIY Drones or the Ardupilot forums for help. The airframe did what it was told and it was home in time for tea and medals, the chap was not going to be able to react to any out of shape condition with neither method at hand and I wondered just what sort of complaint would have happened if it had flown off.

I guess I could be trapped in the old way of doing things you make complete sense JB the systems should now be moving towards being relatively fool proof out of the box. The hard bit getting them to fly has been done. The next much less sexy bit needs work.

Comment by Petr Hubacek on March 18, 2015 at 6:10am

The pity is, that if something sometimes "can be autonomous", "it is autonomous".

Even a car can move when people push it, the driver inside still need a driver licence.

A good remote for Chappie can be one strong fishing net.

3D Robotics
Comment by Chris Anderson on March 18, 2015 at 7:20am

Gary, that's a good example and an interesting observation.

Yes, IRIS+ has a remote, but it's also possible to fly it beyond the range of that remote.  Of course, IRIS+ has a RC-loss failsafe, so when that happens it will return to within RC range, but you're right that out there at the limits of contact something could happen before control is regained (tree, building, etc).

It's also true that a 300m, the operator was probably beyond decent visual line of sight, and might not have been able to be an effective "pilot in command" if the mission needed to be aborted because of some obstacle, even thought there was still technically a remote connection. 

Comment by Gary Mortimer on March 18, 2015 at 8:20am

It showed amazing confidence in the system I thought and his ability to judge the height of the trees over which he flew it. I'm not sure how much the range would have dropped of the TX by putting it on the floor but it can't have helped. Now which would he have picked up if there was a problem? The Iris whipped away as well and I certainly struggled to judge the orientation.

Its great that it worked so well but it masked his lack of handling skills very well and might have lead to over confidence. 

He did'nt even know there were flight sims available, so I guess what I am saying is I am amazed at the knowledge level of some new users.

Comment by Rob_Lefebvre on March 18, 2015 at 8:42am

I'm not at all Gary.  This autopilot technology has made these aircraft accessible and usable to people who have never set foot inside a hobby store.  It's something we have to deal with every day as we write the code and have to consider safety aspects, and what might be "obvious" to us vs. new users.

BTW, I've been playing with Real Flight 7.5 recently, and the multirotor simulation is really very decent.  People should be encouraged to use it to learn how to fly manually.

Comment by Sgt Ric on March 18, 2015 at 8:48am

When this community was truly DIY, we knew (mostly) how the systems worked because we were the ones that built them; and soldered the wires and flashed the firmware, etc., but now that ReadyToRun systems are being bought by kids and part-time half-enthusiasts, aircraft are taking to the skies with less understanding by the "pilots-in-command".

This not not necessarily a bad thing, just the natural progression of the hobby. 

As well, I am amazed at the number of people flying APM machines (3DR and clones) who have not visited 3DR, DIYDrones,, or any of the important sites, but are turning to Facebook and other social sites for help!  

Users are picking up a drone without knowing the basics or even where to find real information. 


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service