Update on Advanced Mission Planning App:
No Promises: But this is looking doable.
To be clear, this would not be an application that would modify the existing Autel Explorer app, this would a stand-alone Mission Planning app with features being rolled out over time. If it works the way I think it should, it would fly the drone mission by uploading the mission to the aircraft and send the initiation commands to launch. Remote PIC would be able override aircraft behavior with the remote controller. (couldn't change that if I wanted to)
PAUSE - LAND - RTH - EMERGENCY STOP etc.
I have a mobile developer interested in working on the project with me. His current skillset is more in line with Apple IOS and he has multiple devices to test against. I am getting a copy of the IOS SDK to him along with some of the data collected so far.
State of the Union:
IOS Developer - CHECK
Android Developer - Not Yet
SDK:
Android SDK: Registered and Downloaded
- No Oblique Mission Types in Current SDK, Might have to brute force this by taking examples from the json files and extending the sdk.
IOS SDK: Waiting to Download and hand off to developer. (No Oblique Mission Types )
- No Oblique Mission Types in Current SDK, Might have to brute force this by taking examples from the json files and extending the sdk.
Pricing Model: TBD
- I hate Ads in mobile apps, I abhor them entirely. If we go through with more than a PoC on this it will likely have a modest price tag.
- Perhaps, if some folks really want a free/discounted version, you can opt in for ad revenue. *puke*
- One Time Purchase Price vs. Subscription Model (maybe both options) .. it's all up in the air ..
MVP:
- The dev team, such as it is, will be meeting next week to dig into SDK's and set the Minimum Viable Product requirements.
- Developer MVP List:
- May range wildly from my own..
- My MVP List: All Versions
- MVP #1: Extrapolate Existing Missions (NewMission.txt - JSON FILES)
- These are stored in non-privileged file system space on Android, not sure about IOS
- 3rd Party App should be able to snag and parse them to feed the answers back into the NewMission SDK. Skips that whole nasty business with trying to gain imposter or root access to the SQLite Database.
- Create Mechanism to Import
- Create Mechanism to Export / Share to Remote Site
- Create Mechanism to Backup to Remote Site
- Create Mechanism to Restore from Remote Site
- Allow - Service Related Site Operated by App Team
- Allow - Secondary Sites - ie. dropbox.com, box.com, OneDrive, google drive, iCloud, etc ..
- Likely to only be one or two of these depending on Operating System of phone/tablet
- MVP #2: Import Mission Files From Common Flight Plan Site - Litchi
- Create Mission Translation from Litchi Fight Plan Style to Autel Missionese via SDK and Data Transformation Libs
- The whole reason I started this goofy task was so I could have native HiveMapper missions.
- So that's something I want in the MVP
- My Wish List: (Back-Back-Backlog Items)
- Hobbyist Mode (License Level)
- Small/Medium Business (License Level)
- The things most of us would use.
- It occurs to me that vertical surface mapping is sorely lacking in Autel Explorer. It would not be too hard to replicate this but defining a maximum flight alititude, create a horizontal pass with camera actions, drop the altitude for desired vertical overlap, create a pass, drop the alt.. etc .. then define the overall area to be flown by outlining the structure or area in a polygon.
- Representation of the object could be drawn in the app as a shaded volumetric object, with low poly grids filled in as the images are taken .. perhaps fill it in with screen grabs from the live view as camera is actuated. *gotta noodle this some more*
- Enterprise (License Level)
- Crazy Large Business Centric Items .. would have to be really worth it to program and include.
- Safety First Mode - Require Complete Checklist Before Mission Authorization
- More of an Enterprise Feature - Tied into Desktop Planner Roles (wishlist item)
- Allow Remote PiC To Enforce Safety Checklist Completion
- Password/X.509 Certificate Authentication Required to Override
- NFC X.509 Authorization / Lockout to Allow the PIC to Enable the Mission
- CRM Integrations
- GIS Package Integrations
- Mission Pre-Flight and Post-Flight Checklists:
- Probably more US Centric with Part 107 Requirements being service first.
- Other Regulatory Zones could be added
-Casey
So, to recap:
The missions are defined by arbitrary third-party tools. This leverage creates tremendous value, of course.
The flight time procedure is: Toss Explorer aside and run the NaughtelMission app that obtains the mission definition solely to "load and fire." At this point the app becomes largely irrelevant. Indeed, the controller (RC) is fully autonomous and so the attached phone/tablet would be (presumably/hopefully) superfluous.
Poosible problems:
Clearly, the drone sends (some kind of) status to the RC regularly. When Explorer supervises a mission, it reports progress to the PIC in terms of actual position and bearing (general navigation reports) as well as waypoint progress (mission-specific). It is unclear whether the mission-related reports to PIC are inferred by Explorer or the RC FW based on position, or reported explicitly by the drone. I strongly suspect the latter. Either way, it would be extremely reassuring to have a similar reporting capability for the new app. Even if I was highly confident that the pause/RTH functions of the RC would override any flight plan, I would be uncomfortable as PIC if I was unable to precisely monitor the logical progress of a mission. I'd want it all - maps, live video and waypoint reports. Even the Explorer reporting is sparse for my taste.
Anyway, indeed there is a SDK method: setBreakPointMissionListener(). There is also cancelMission() in the Evo2FlyController interface.
Anyway, perhaps the Explorer app would be amenable to proper mission monitoring even if initiated by a different app. If so, it suggests that the drone status reports are RESTful, so to speak. Not unlikely? OTOH, if I were to offer this app to anyone as a product, I'd consider inbuilt mission monitoring as a basic, mandatory feature. It would be clumsy if not disruptive to switch apps communicating on the RC interface mid-flight.
So these questions relate to the usage of the Evo2WaypointRealTimeInfo Interface and implementing classes.
Relatedly, since all control and reporting is channeled through the RC via USB, it leaves open questions: How much of the functionality exposed by the SDK is actually implemented in the RC firmware? Also, is there some kind of authentication one must use to drive the RC that Autel controls (doubt it, but presumably surmountable because they provide the SDK).
Coincidentally, I was annoyed by the inability to spec a Rectangular or Polygon mission that records video instead of snapshots - in order to use with Hivemapper. That's why I was inspired to simply hack the JSON for one of those missions to do video.