Welcome, Autel Pilots!
Join our free Autel drone community today!
Join Us

Mission Planning File Locations: Android

Bill,

In regards to the JSON file being for show, I am not sure if I would agree entirely. In the decompiled code there are references to the JSON but they are just stubs.. If I were a betting man, I would say this was the devs way of paving the road for missions import and export, but never finished or they are waiting to extend it for some kind of "Enterprise" model support, perhaps the RTK series or Dragonfish. Because surely the hobbyists and Small Commercial pilots wouldn't need it .. *SMH*

-Casey
Come to think of it - maybe it's simply the transfer format chosen for upload to the drone. Saving it to persistent storage - as opposed to generating on the fly (heh) - is cheap enough, with the added benefit of having it around for QA/debugging.
 
I haven't gotten a dev on-board yet, but I did find some very useful information about the mission.db yesterday. I am going to fly a few missions on my rooted phone as soon as the stormy weather clears up to confirm my findings. I will keep you apprised.

-Casey
 
  • Like
Reactions: autelBill
Come to think of it - maybe it's simply the transfer format chosen for upload to the drone. Saving it to persistent storage - as opposed to generating on the fly (heh) - is cheap enough, with the added benefit of having it around for QA/debugging.
Bill,

Good ideas:

I had a few thoughts along those lines and brainstorming and looking for a way to monitor the traffic between the App and the UAS to see what is getting uploaded to the IMU storage. That is the reference to my test flights that the storms have put on hold.

To be honest, if the JSON body is the mode of transfer to the UAS's on-board systems, that would be the best outcome. Skip the app designer and just generate an output Plugin or converter for one of the existing mission designers.

I really do hope it is that easy.. LoL

-Casey
 
Bill,

Good ideas:

I had a few thoughts along those lines and brainstorming and looking for a way to monitor the traffic between the App and the UAS to see what is getting uploaded to the IMU storage. That is the reference to my test flights that the storms have put on hold.

To be honest, if the JSON body is the mode of transfer to the UAS's on-board systems, that would be the best outcome. Skip the app designer and just generate an output Plugin or converter for one of the existing mission designers.

I really do hope it is that easy.. LoL

-Casey
Doesn't that presumes that the Explorer app can be induced to use the JSON for the mission selected? I've inferred from this thread that the JSON is a side effect of the process of designing the mission with Explorer but that the mission.db is used as the as the authoritative source. So one might assume that if I use the app to select a mission it will not find any JSON that spontaneously appears in the FS. Or not?

I'm inclined to believe that the JSON is produced/regenerated when the user uses the "save" function of the mission planner and that the mission.db is updated dynamically during the editing process. This would comport with my recollection and experience of typical Android programming practice. If that's the case, one could conceivably dump a modified "imposter" JSON file in place of an existing mission prior to upload/execution. The hazard here is that the mission.db plan would not match and if used in the app to monitor progress as it normally does it could create confusion or chaos.
 
Doesn't that presume that the Explorer app can be induced to use the JSON for the mission selected? I've inferred from this thread that the JSON is a side effect of the process of designing the mission with Explorer but that the mission.db is used as the as the authoritative source. So one might assume that if I use the app to select a mission it will not find any JSON that spontaneously appears in the FS. Or not?

I'm inclined to believe that the JSON is produced/regenerated when the user uses the "save" function of the mission planner and that the mission.db is updated dynamically during the editing process. This would comport with my recollection and experience of typical Android programming practice. If that's the case, one could conceivably dump a modified "imposter" JSON file in place of an existing mission prior to upload/execution. The hazard here is that the mission.db plan would not match and if used in the app to monitor progress as it normally does it could create confusion or chaos.
The MissionManager interface in the SDK might provide insight, although I'm not inferring anything from what I'm seeing at the moment. But if it was my code, I'd regenerate the JSON upon the downloadMission call to play it safe.
 
Keep in mind that if you want elevations, you need to enable online elevations in the mission settings within litchi (e.g. via litchi hub). Also you will want to verify your waypoints to see if they are using MSL, or, you can select above ground. Also note that there are two different kml's that can be exported from litchi hub, one is the vml for google earth, the other a regular kml.
All boxes checked except CSV. Tried the straight KML from the hub. Will try CSV to KML converter. Thanks. Imported Kml was empty in explorer. Just didn't work.
Just curious, have you guys ever seen or used Dronelink? The Autel platform is not currently supported, but it is on their To-Do list. I have used it with my Mavic Mini and I really like it and it has some great capabilities. It is currently the most requested functionality posted on their product roadmap. Please visit if you get a chance and add requests to support the EVO II! Trello
Will do!
 
  • Like
Reactions: gschulzuio
Pix4D, the folks behind DroneLink seem to have a good working relationship with Autel Robotics so far. It bodes well for a 3rd Party mission planning platform. If happen to own a recently sold Evo II Pro Rugged Bundle you will note that it came with a 1 year subscription to Pix4DReact. A rapid deployment isomorphic mapping package that is supposed to play well with the Evo II. I haven't activated my subscription yet, but I will give it a go.

-Casey Annis
 
  • Like
Reactions: autelBill
Pix4D, the folks behind DroneLink seem to have a good working relationship with Autel Robotics so far. It bodes well for a 3rd Party mission planning platform. If happen to own a recently sold Evo II Pro Rugged Bundle you will note that it came with a 1 year subscription to Pix4DReact. A rapid deployment isomorphic mapping package that is supposed to play well with the Evo II. I haven't activated my subscription yet, but I will give it a go.

-Casey Annis
I bought my Evo II Pro Rugged Bundle in the end of March. I did not see anything that mentioned this 1 year subscription. Do you have any details you could share?

Thanks
 
I bought my Evo II Pro Rugged Bundle in the end of March. I did not see anything that mentioned this 1 year subscription. Do you have any details you could share?

Thanks
I purchased mine about 7-days ago, with the GPC case Rugged bundles from EmpireDrone. In the bottom layer, under the airframe tray, was a folder with the subscription information.

I can provide some more details in the morning.

In the meantime: Here is the Pix4D Press Release about the partnership.

-Casey
 
You will need to fill out the form linked in the QR Code with your Rugged Bundle SN to see if your eligible for the 1yr subscription.

Pix4D will email a license activation if you match up.

Best of Luck,
-Casey
20210513_073739.jpg
 
If that's the case, one could conceivably dump a modified "imposter" JSON file in place of an existing mission prior to upload/execution. The hazard here is that the mission.db plan would not match and if used in the app to monitor progress as it normally does it could create confusion or chaos.
Bill,
I would absolutely like to avoid chaos at all costs..

If the method to "upload" a mission to the aircraft involves pushing the JSON .txt file to the aircraft. It would indeed be chaotic if the aircraft flight path differed from the mission designed in the app. In this instance it would probably be prudent to develop a 3rd Party app using the SDK.. "Autel Evo Advanced Mission Planner" or some such..

The mission tracking screen would need to be a part of that new app.

I don't want to leave out the IoS users, but I don't have one and Android devices far out number IoS atm. 87% market share.

-Casey
 
  • Like
Reactions: autelBill
I tried renaming a mission from my tablet with the extension KML and on my fone it did give me the opportunity to find it in the new missions folder, but it gave me this mysterious alert when I tried to import it. Translate?kml_ooops[1].jpg
 
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
 
  • Like
Reactions: TheGoldBug
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.
 
  • Like
Reactions: TheGoldBug
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.
Bill,

My apologies,

I left out a stement that we would only consider further development if we could maintain flight monitoring in some fashion.

It would highly reckless of us to toss the UAS in the air and 'hope' all goes well. Lol

Monitoring would absolutely be required to enforce safe operation.

If you tail the logs during a mission the aircraft sends back progress messages. These messages are being written to the mission database.

I would expect the messages are being sent to a designated endpoint running in the app and that continued heartbeats are required to ensure control of the aircraft during the mission.

We want to keep app parity in that regards.

-Casey
 
Bill,
I would absolutely like to avoid chaos at all costs..

If the method to "upload" a mission to the aircraft involves pushing the JSON .txt file to the aircraft. It would indeed be chaotic if the aircraft flight path differed from the mission designed in the app. In this instance it would probably be prudent to develop a 3rd Party app using the SDK.. "Autel Evo Advanced Mission Planner" or some such..

The mission tracking screen would need to be a part of that new app.

I don't want to leave out the IoS users, but I don't have one and Android devices far out number IoS atm. 87% market share.

-Casey
Dronelink has it in their to-do hopper to provide support for the EVO II. Dronelink supports both IOS & Android. They just need a little more encouragement to move it to the front of the line!
 
The Autel Explorer for Android (v.1.1.7.38) imports this KML created in the Google Earth. There are two things to do right after import:
1) zoom out the map to see the whole world (otherwise you will not see a route that is far from your home location);
2) press the flight direction reverse button (S <-> E) twice to make the route visible.
I could not find the format that the iOS version imports - the crash is guaranteed.
 

Attachments

  • LineMission.zip
    1.3 KB · Views: 3
Got this. I'm out of time today but wonder if the kml from this url will work.

With what limited time I had, I extracted linemission.kml and it doesn't show up in the file selector likely because it's too far away. My kml of a simple flight log shows up an imports, but it's "empty", no lines. How the flight log file looks in GE.

Image2.jpg
Image1.jpg
 
Last edited:

Latest threads

Members online

Forum statistics

Threads
11,228
Messages
102,655
Members
9,818
Latest member
redwingaerials