Proposed "Continue Mission" option on loss of comms with Controller requiring downgrade of mission options
I read the Dronelink FAQ article entitled "What Happens if the Drone Loses Connection"
In the article it states that "Continue Mission" is being considered as an Option for loss of communication (on compatible drones), but would result is loss or downgrade of features currently enjoyed by the Dronelink community - due to the "virtual stick" programming of Dronelink, as opposed to aircraft upload (which involves limitations) as used by other apps (such as Litchi).
I have three questions:
1. What are the features Dronelink currently offers in its flight controller which would not be possible if the mission were to be uploaded to compatible aircraft? (eg: in addition to what something like Litchi currently offers)
Is it things like being able to combine orbits and waypoints into a single mission?
Or programming intermediate points for altering points of interest etc?
On this second point I expect this sort of thing could be handled by the Mission Planner in its existing manner (so it doesn't alter flight path etc) and then get converted to something like an additional waypoint on aircraft upload.
2. What sacrifices must be made to have a "Continue Mission" option on aircraft loss of communication with the controller (with compatible Drones)?
3. Can this be made into an option that does not affect the normal options and planning in Dronelink (and therefore nobody has to sacrifice anything), but should it be selected it would then trigger a warning of downgraded mission performance and then convert the mission as programmed into something compatible with an aircraft upload (or give a warning that the mission as programmed is incompatible with this mode)?
I currently have Litchi. Personally I find Litchi a little clunky and limited for what I was expecting. It works great once you get it sorted and uploaded to the aircraft (M2P in my case), but I believe the "Mission Hub" GUI could be improved to make programming easier.
For Example:
- Litchi has a global mission parameters setting window called "Settings". In Settings you can select that the drone aim the gimbal "Towards the Next Waypoint" (TNW). If you then put in a Point of Interest and then instruct one or more Waypoints to "Focus POI", it doesn't override the overall mission setting of "TNW" and the drone remains pointing towards the next waypoint (the gimbal raises and lowers accordingly, but that's a bit redundant if the aircraft won't rotate).
- So you then change the Mission Setting for the gimbal to "Waypoint Defined" (WD). Insread of staying where they were, every Waypoint then points towards the POI!
- The annoyance then becomes that you cannot select multiple Waypoints for a single change. "TNW" is also not an available aircraft heading on the Waypoint settings (only the global mission "Settings"), forcing you to program the heading manually, which is difficult with the little aircraft icon to get exactly right (an extended axis line would be useful!), not to mention its time consuming.
- I do not see why Towards Next Waypoint (TNW) cannot be a setting to be applied on a waypoint via the Mission Planner, and the Planner then has the job of converting it into a heading before it uploads to the aircraft (it probably does this anyway, so why not just make it a user option).
There must be a multitude of settings (such as I've stated above) on the current Dronelink Mission Planner which can remain as slick and user friendly as possible, which could then be converted by the Planner into parameters that can be uploaded to the aircraft such as in my example above, a heading setting on a waypoint can be "Towards Next Waypoint", and the Mission Planner simply converts that into a heading.
I mean the planner itself must work that way in converting points on a map, gimbal angles and photography, into a language the aircraft can speak.
There must be a certain amount of slick programming that can be done on a well made GUI which can then be "dummed down" to make it compatible with an aircraft upload. And if a "Continue Mission on Loss of Communication" option is made available, it warns you and dumbs down the available options on the GUI to those that can be made compatible with the aircraft.
That's how I see it.
I do realise that you're trying to make money, and the coding I've just described could be years of work, and make the app $500. People won't pay that (in fact, people balk at paying $20, which I find nuts considering its pocket change in comparison to the cheapest decent drone)!
I'm going to buy Dronelink, if for no other reason than I think it will be a better experience than Litchi.
Regards
Martin Hocking
Comments
3 comments
The brutalist way to look at it would be nearly every feature except a subset of the Path component.
The nearest thing to the Path component that the DJI SDK offers is the waypoint mission, which allows developers to specify missions with up to 99 waypoints, and these waypoint missions can even be scheduled in sequence by using the timeline in the mission control interface.
The difficulty begins when you realize that all settings must be applied at waypoints, whereas Dronelink uses markers which can be spaced at arbitrary points along the Path. Furthermore, when you look at the list of available options that can be configured at a waypoint vs what can be accomplished via markers, there are often no substitutes.
For example, Dronelink allows the execution of any arbitrary drone, camera, or gimbal command whereas DJI waypoints have a very limited action set consisting of start/stop camera capture.
Another example is DJI waypoint missions only support rounded corners and not bezier curves. We could place additional waypoints down (as you say) to approximate the curve, but you very quickly hit the 99 waypoint limit with approaches like this. You end up having to schedule multiple waypoint missions in the timeline, which will of course bring the drone to a complete stop between the missions, which ruins shots where people are looking for continuity in motion.
These are just some of the issues with Path component, and as you know, we have many, many other component types to consider:
We might be able to figure out a way to fake some of these component types as DJI waypoint missions, but many of them are going to have even worse trade-offs than Path.
For example, Map component with terrain follow over large areas would probably need to be split into so many sub-missions (due to the 99 waypoint limitation) that I am not even sure the DJI SDK could handle it. Much testing would need to be performed to determine the limits of the Mission timeline.
Other components, such as Facade and Inspection (which currently support 20 batteries / 4000 frames) probably cannot be executed safely at all. These types of components are meant to fly up close to structures (within a few meters), and it is very difficult to do this safely with most DJI drones because of the underlying sensor errors that constantly occur (the GPS and barometric altimeter can be off by +- 5 meters!). We created an adaptive flight module that allows pilots to make adjustments to the mission in real-time (to overcome the observed sensor errors), and this is only possible when using virtual stick. When you upload waypoints, the controlling app no longer has any command authority to make adjustments.
Having said all of that, if/when we do decide to implement what we are calling Onboard Compatibility, it will probably be as you say: you will have to select the option in the UI and then the UI will have to remove many of the features that we could not find a way to convert. Even then, my guess is that the features that we are able to convert will not be 1 for 1, and helping users understand the differences will probably be fairly difficult. In the end, implementing this functionality is a massive undertaking and the risk/reward is unclear at the moment. We understand there are certain use cases and regulatory environments were disconnected missions make sense and are legal, but at the same time we need to be realistic in terms of the markets that we are targeting. For example, one of the primary use cases for Dronelink right now is critical infrastructure inspection, and this body of work will do nothing to help that use case as it is dependent on our more advanced component types that need adaptive flight (Facade, Inspection, etc).
Excellent write up addressing my queries Andrew, thankyou.
Onboard compatibility is now available for beta testing.
Please sign in to leave a comment.