UK 3rd Party Control Software and Ops Manuals

[IrishSights]

Just wanted to start a discussion on implementing, for commercial use, 3rd party flight control apps such as Autopilot, and Ground Station apps such as Dronedeploy, Pix4D etc. Specificly if you think ammendments need to be made, and what, to CAA Operations Manuals before these apps can be used. My Ops manual was prepared before any of these apps were available.

Obviously we can't amend our Ops manuals every time DJI decide to add new functionality to their firmware/App. Having said that I think preflight procedures may need to be amended if these semi-autonomus functions are used. Covering mission planning, additional safety checks and inflight procedures when the missions are engaged and the integration of FS/mission cancelling.

Thoughts?

 

[Scotflieger]

I too have been thinking about the amendments I need to make to my UAS OSC for both hardware and software changes I have introduced since I submitted mine to the CAA. These changes will need cover such things as strobe lights and Zenmuse X5 to the use of DJI's Intelligent Navigation (IN) modes, Autopilot and Maps Made Easy. Which of these will offer commercial benefit and how safe the use of automated software would be seen in the CAA's eyes?

Hardware and standard firmware changes are already covered in my UAS OSC. Hardware changes/modifications and software/firmware updates need to be recorded in the aircraft maintenance history log. However, I have only some holding text for the then anticipated DJI ground station, now IN, functions. Do these automated modes override the standard minimum distance and continuous visual line of sight requirements? Provided the pilot can monitor and take control when necessary then one could say that whether we are flying manually, with GPS stabilisation or semi-automated makes little difference.

I think we need to keep our manuals to the standard and practices we are working too. The question is how often these updates should be submitted to the CAA? Is there a supplemental charges for such interim changes? It has proven difficult to elicit any feedback from the CAA UAV office on what PFAW holders should or need to do.

 

[The Editor]

To answer your questions:

There is no additional fee for submitting amendments to your ops manual (or changing versions) - it simply must be lodged with them.
Your standard permissions are just that - Adding automated flight etc does not alter your existing restrictions or enhance them regarding VLOS etc
You are correct in your statement regarding changes to hardware/payload software which would be recorded in your maintenance log.
Depending on how you advised your MTOM in your manual would depend on whether you need to submit any addendum - I stated my MTOM for my Inspire as the maximum rated payload (which is 3.5kg) minus the weight of the existing X3 plus the additional weight of the TB48's which from memory totaled around 6.2kg. So provided my MTOM does not exceed this threshold or my payload does not go over 3.5kg I do not have to inform them of anything.
Software updates should be taken care of within your ops manual under something along the lines of "Software and Firmware Update Policy"
Autonomous flight modes are simply a feature of the aircraft system (once the software/app is loaded) and provided you are operating within your restrictions an addendum documenting any change in pre, during and post checklists should suffice. (The DJI intelligent flight modes actually make things a little easier since your pre flight checks will remain unaltered since you cannot access these modes until airborne.)

Hope that helps.

 

[Roger Pearson]

My understanding is that the CAA and Ops Manual / FRCs are there to cover the basic operational configuration of the aircraft. That is, the aircraft itself, with whatever different sensor payloads you have (X3, X5, NDVI...) , any changes you may have made to the hardware (strobes), and the vendor-supplied GCS, which for the Inspire is the pilot RC. There are a few aspects of configuring and monitoring the flight operations of the Inspire that are easier to do or have to be done via the DJI Go app (and third party software such as DroneDeploy, MapsMadeEasy, Pix4D, etc... all read and use the settings in the GO app via the SDK interface) [Amendment: AutoFlight Logic does not - it uses it's own flight controller, so be aware of that], but beyond this you don't need to include any of these tablet apps / operations in your Ops manual. You should, however, make sure you cover all DJI standard functionality and this includes Intelligent Flight Mode & Waypoints ( although this ought be in there already as it had been well documented by DJI). Everything else, all other functions and operations, are from a higher-level software stack that sits on top of this core functionality, and all safety and recovery modes are at this core level and on the flight controller / RC. The CAA isn't interested in what mapping app or cloud processing system you are using ( although the Data Protection Registrar might be!) just that the core platform and operation thereof is safe. If a map app crashes mid-mission it has already uploaded the waypoints to the aircraft (which it does Post take-off when DJI allows it, just as with the GO app), so the aircraft is going to continue its mission just as if you'd manually set this via the DJI GO app. Furthermore, the 3rd party apps own checks should always fall within your own. If not, you are missing something important from your pre-flight. So, and as The Editor says above, nothing really changes from what should already be in your Ops Manual.
I would add that as a user of the aforementioned apps and also as an owner of a dual controller setup I find it useful to keep the DJI GO app on the second screen to better monitor flight operations. In commercial operations this really ought be off-tasked to your camera operator who may not have much else to do in these fully automated flights. (Errors, warnings, flight mode, signal levels, battery status etc all current display in GO much better than the other apps)

 

[IrishSights]

Thanks everyone. IFM/waypoints came into being after my Ops Manual was first written. I presume i just add it at renewal time. Hardly worth submitting an ammendment mid stream?

 

[Roger Pearson]

(The DJI intelligent flight modes actually make things a little easier since your pre flight checks will remain unaltered since you cannot access these modes until airborne.)

As stated, DJI Waypoint system doesn't come into play until AFTER take off so falls into IN FLIGHT procedure. Depending on how you have that written and assuming it's not long until your annual renewal an amendment with renewal should be fine. I know Gerry and the poor guys in Gatwick (CAA) would be OK with that. If you are using AutoFlight Logic you may need to look at other areas, though, as this is a different flight controller and will impact your pre-flight and safety procedures as well and so is a bit more important. Their flight logic is well documented, but there are differences in there such as Dynamic Altimeter Reference, Altitude Priority, Max Power (which will impact your platform performance in avoiding action situations), which are not the same as DJI's. If you are using AFL then you probably need to do an interim update to your Ops Manual.

 

[IrishSights]

That's great, thank you for the input. Even with Autopilot I would never engage before take off, always do it with with DJIs FC. I like to get it in the air and all initial checks done before I would engage any SDK app. So in this situation even if it's a different FC would you still advise an ammendment as preflight procedures remain the same and via DJI's FC?

 

[Roger Pearson]

An addendum would probably cover it. The CAA guys are busy enough and don't want or need to see a load of minor changes crossing their desks. Does your Ops Manual have a line somewhere that says something like:
If the Flight Controller / App crashes / becomes unstable / unreliable then change flight mode to ATTI and land? If so and you are following all other procedures as per your Ops Manual and your IN FLIGHT says something like PROCEED TO MISSION OBJECTIVES, which gives you freedom to then load AFL at that point (provided you take care to apply the same safety settings as the GO app), then an addendum should be fine and just update on renewal. If not, you might need to address that gap in your safety procedures to cover alternative FCs and at the same time caveat the operational changes of the alternative FC. You may also want to check your PRE-LANDING starts with checking / returning flight control to PILOT (ie disabling AFL). (Although one could argue exiting AFL is part of your MISSION parameters and you could equally cover the use and operation of AFL in you mission planning documentation on a per-mission basis as you will not necessarily always use it) Remember that the existing regs and procedures come from manned aviation and if you changed something like this in manned aviation it would have to go through an accelerated retest and recertification procedure. A lot of this is likely to be simplified over the next few months / years, but as well as making sure you are safe I'd be thinking more in terms of covering your *** from an Insurance perspective rather than a Regulator perspective, now. The way regs are changing it is the insurance market that is going to be dictating the bulk of what we do and don't do on commercial SUAS in the future. When you are stood in front of a judge with a tenacious prosecutor who asks "Can you tell us what your procedure was for x and did you follow it?", the rope is around your neck and it basically boils down to a yes or no answer whether he gets to kick the chair from underneath you. So you need to make sure your procedures are watertight and whether that is an addendum or a change or something in you mission planning will boil down to the wording in the procedures you already have and how significant a change to your Ops Manual you need to make, if any. If in doubt, ask your (or any) NQE. My take on it is this: A significant change to platform performance and / or safety procedures is something they are going to want to see immediately. A minor change to wording in existing procedures that has little effect on them can be done on addendum. Per-mission specific stuff that comes out of mission planning and risk assessment is not relevant to your ops manual. In my case I only use AFL occasionally and I also have a couple of notes on my platform tech specs indicating different FCs can have a performance impact. My use of AFL is then covered outside of my ops manual in my per-mission docs, but that is because I do a lot of R&D on the platform so need that flexibility.