Sooooo..... Whose returning their P4?

[Ibmftw]

P

 

[Tenly]

I honestly have not bothered looking into the warranty situation where object avoidance is concerned I do not imagine the warranty T&C's would be that specific there is room for a grey area here people could lie and say the phantom hit a brick wall, and after DJI checks it and says well the object avoidance didn't detect anything the user can then say "exactly but it was on and the birds heading was forward" it's a slightly tricky situation.

Surely the magical flight logs which contain the reams of data and telemetry will show conclusively which orientation the bird was facing/moving when the accident occurred as well as conclusive proof as to whether or not a object avoidance was active? I don't think OA changes anything with respect to tpeople crashing and lying to claim hardware malfunction. That's the biggest reason those .dat files exist! In any case, I'm sure we'll hear the stories soon with the weather getting nicer and more and more people upgrading.

The thing with software faults is they are usually discovered after its too late, the WEP wireless security protocool was once considered secure.

I'm an IT guy and I don't remember a time that WEP was considered "secure". It was considered "secure enough" when it first came out - but not actually secure. In any case - I get your point. It's hard to write a bug free piece of software - especially when you are relying on some else's SDK/APK to do a lot of the work - having said that - extensive testing can minimize the chances of a catastrophic failure and good error trapping/monitoring routines can implement failsafes" which kick in when something fails and mitigates the danger of the failure.

Litchi's main selling point in my opinion is being able to execute an autonomous mission, which is real fun once you take the leap of faith, I have had some tense 20 minutes waiting to see that video link appear again or hear some blades spinning ha ha, but it honestly has run faultlessly for me, carefully planning, checking and rechecking of GS missions before take off is key! You will be able to fly places and get footage that would otherwise be impossible, for me that makes the app worth its cost alone. The app is now no slouch in the feature department either and you can dig pretty deep with "actions" at each way point including auto focusing on the on POI's to start/stop recording/photos, manual heading selection between Waypoints, rotation control at and between Waypoints, a stay command etc, I use Litchi almost exclusively for its GS (ground station) mode. As for Litchi on iOS I notice it is slightly slacking and haven't and do not use it on iOS so couldn't recommend it, however like I say even if autonomous Waypoints work flawlessly on iOS I would buy the app for that alone.

I agree about the autonomous missions. The Autopilot flight school talks about possibly releasing a mode in the future that would continue the mission on loss of signal but no promises and no ETA. I'm going to solve the problem another way - getting one of the antenna booster nods - either dbs02 or fpvlr which should keep me from losing signal during my waypoint missions.

Some of the features you describe with regards to waypoint missions sound really cool - and coincidentally, I've already posted a message Ina different thread that I hope autoflightlogic will see asking for them (the stopping to perform an action at each waypoint) - but I think Autopilot probably wins hands down for the number of ways you can control the camera between waypoints. It can do everything you described and far more. For every autopilot mission there are separate controls that define what the camera points at and which way the device travels. They are configured separately and there are countless options for each. One of my favorites is the ability to have the camera maintain focus on a separate, moving target

 

[Tenly]

Disengage on Answer Phone Call is actually a setting that can be disabled. That is, if you answer the phone you can allow Autopilot to continue to fly in the background, but we wouldn't recommend it.

Do you guys have any kind of public roadmap for Autopilot? When can we expect to see the next version and what changes/new features are expected to be in it?

 

[Hangar]

The Autopilot flight school talks about possibly releasing a mode in the future that would continue the mission on loss of signal but no promises and no ETA.

The question on implementing LCMC is, will you still be satisfied with using Waypoint Mode without all of these unique features? Particularly, once the aircraft loses connection, Autopilot can no longer control the gimbal, so for the duration of the disconnection, you are stuck at one gimbal pitch (and yaw on the Inspire). For mapping missions where the gimbal is pointed straight down, this seems acceptable, but this isn't what most of our users are currently using Autopilot for.

It's hard to write a bug free piece of software - especially when you are relying on some else's SDK/APK to do a lot of the work - having said that - extensive testing can minimize the chances of a catastrophic failure and good error trapping/monitoring routines can implement failsafes" which kick in when something fails and mitigates the danger of the failure.

It is incredibly hard, but we take safety and QA very seriously. As of the date of this posting, we are proud to report that there have only been 12 reported incidents with Autopilot (out of over 60k flights) and all of them were determined to be operator error. Having said that, we take full responsibility for our software and will perform a complete crash analysis for any reported incident. If it is determined that Autopilot is at fault, we will of course replace your hardware.

the stopping to perform an action at each waypoint

This is already coming in 3.3 starting with Waypoint Hover actions. See the full changelog here.

Do you guys have any kind of public roadmap for Autopilot? When can we expect to see the next version and what changes/new features are expected to be in it?

We keep the summary changelog up to date as we release beta builds, and you can also see a detailed changelog here for each individual build.

 

[realsting]

Huge difference between 28 mins and 18 mins ...... If it were 2/3 mins off.... Ok..... But 10 mins and the bAtteries cost $50 more... Lmao.....and 3 miles to 1 miles......lost signal.....cheers to you bro..... Go buy 5 more batteries..... There's a sucks born everyday.... Jus sayin

Yes and maybe a huge difference between your flying conditions and the the ones DJI had.

Take a look at this:

Looks like someone might be ordering another P4!!! looool

 

[Ibmftw]

Surely the magical flight logs which contain the reams of data and telemetry will show conclusively which orientation the bird was facing/moving when the accident occurred as well as conclusive proof as to whether or not a object avoidance was active?

Yes this was exactly my point I. E. The user could have hit a branch that OA didn't detect DJI would have no way of knowing, but they would know from the tele data and log that OA was on and the craft was heading forward.

 

[Ibmftw]

I'm an IT guy and I don't remember a time that WEP was considered "secure". It was considered "secure enough" when it first came out - but not actually secure. In any case - I get your point. It's hard to write a bug free piece of software - especially when you are relying on some else's SDK/APK to do a lot of the work - having said that - extensive testing can minimize the chances of a catastrophic failure and good error trapping/monitoring routines can implement failsafes" which kick in when something fails and mitigates the danger of the

Nice to know, I'm also an IT guy (security consultant) mostly testing server side web frameworks but I have been responsible for a few SDK patches being issued also. I have not even bothered looking at how phantoms deal with data exchange security but I can guarantee you it wouldn't be a priority of theirs as they are building a platform that is mostly based around a system with giant security flaws from the get go, regular GPS.

I'm going to solve the problem another way - getting one of the antenna booster nods - either dbs02 or fpvlr which should keep me from losing signal during my waypoint missions.

I think either of these mods are massively worth doing even if you do not fly massive distances, the lower alt. flights and punching power through obstacles do give a better experience in my opinion, again not for EVERY user but for me, definitely, and sounds like for you would be great too.

Some of the features you describe with regards to waypoint missions sound really cool - and coincidentally, I've already posted a message Ina different thread that I hope autoflightlogic will see asking for them (the stopping to perform an action at each waypoint) - but I think Autopilot probably wins hands down for the number of ways you can control the camera between waypoints. It can do everything you described and far more. For every autopilot mission there are separate controls that define what the camera points at and which way the device travels. They are configured separately and there are countless options for each. One of my favorites is the ability to have the camera maintain focus on a separate, moving target

Is the Autologic app restricted on android in the way Litchi is on iOS? If the answer is no, then I will give it a whirl for sure.

The question on implementing LCMC is, will you still be satisfied with using Waypoint Mode without all of these unique features? Particularly, once the aircraft loses connection, Autopilot can no longer control the gimbal, so for the duration of the disconnection, you are stuck at one gimbal pitch (and yaw on the Inspire). For mapping missions where the gimbal is pointed straight down, this seems acceptable, but this isn't what most of our users are currently using Autopilot for.

I presume this is because the flight controller and not a restrictive implementation of the SDK, as I am sure you aware Litchi can change gimbal pitch during autonomous flights.

It is incredibly hard, but we take safety and QA very seriously. As of the date of this posting, we are proud to report that there have only been 12 reported incidents with Autopilot (out of over 60k flights) and all of them were determined to be operator error. Having said that, we take full responsibility for our software and will perform a complete crash analysis for any reported incident. If it is determined that Autopilot is at fault, we will of course replace your hardware.

So you are essentially saying you have a fatal error rate of 0, that speaks volumes for DJI's SDK and your guys coding, especially on such a complex implementation WELL DONE, also well done on taking the time to look into people's error claims and openly stating that you are ready to take liability and compensate users on any problems your end, but the fact that you are here partaking in this thread because your company was mentioned and doing so without even slighly incenuating that your platform is better than the compettiors, speaks volumes anyway, I will be taking a look at your app.

 

[Hangar]

Is the Autologic app restricted on android in the way Litchi is on iOS? If the answer is no, then I will give it a whirl for sure.

Autopilot is not an Android at this time, but we are investigating it. The question we always ask to users is: what is it about the current Android offerrings that makes you desire Autopilot on Android? To put it another way, of the features that are unique about Autopilot relative to the competition that is already on Android, which features excite you the most?

I presume this is because the flight controller and not a restrictive implementation of the SDK, as I am sure you aware Litchi can change gimbal pitch during autonomous flights.

To our knowledge it is precisely because of a limitation in the SDK. In fact, all the SDK documentation and user feedback we have seen states that Litchi (or any other 3rd party app) is unable control the gimbal while connection is lost.

So you are essentially saying you have a fatal error rate of 0, that speaks volumes for DJI's SDK and your guys coding, especially on such a complex implementation WELL DONE

That is exactly what we are saying, and we publish the flight total right on our home page. It is an incredibly hard task and we have many thousands of flight hours testing the flight controller internally.

without even slighly incenuating that your platform is better than the compettiors, speaks volumes anyway, I will be taking a look at your app.

Knowing what it takes to create a product like Autopilot, we have nothing but respect for the other product offerings in the marketplace, and at many times and in many places we have stated that users should use the tool best suited to their mission. Right now, if you mission is LCMC, that tool is not Autopilot. Use the other apps for those missions, and use Autopilot when you need to do the things that only Autopilot can do.

 

[Tenly]

The question on implementing LCMC is, will you still be satisfied with using Waypoint Mode without all of these unique features? Particularly, once the aircraft loses connection, Autopilot can no longer control the gimbal, so for the duration of the disconnection, you are stuck at one gimbal pitch (and yaw on the Inspire). For mapping missions where the gimbal is pointed straight down, this seems acceptable, but this isn't what most of our users are currently using Autopilot for.

Ok - so - my mission is fly around an island about 15m off the shore and about 15m above the lake. Currently, my focus strategy uses "direction" and 275 degrees relative to the "course" of the drone. I lose connection when the drone rounds the far corner of the island and I lose line of site. Are you saying that I would not be able to maintain the 275 degree aircraft yaw through the remainder of the flight or are you saying I wouldn't be able to alter the strategy until the connection was re-established? The island doesn't have a flat shoreline and I've used waypoints to fly nice curves paths in and out of each bay. So given that that camera focus is accomplished by yaw on the Phantom 3 (the vertical angle is fine as a constant -15degrees) - what would happen to the existing yaw of the aircraft when connection was lost? Would it just start flying nose-forward towards the next waypoint - or does it remember the last orientation and maintain it?

As for waypoint actions - I'd like to be be able to do a panorama, and/or 2 orbits (1 for video and the second for photos) at certain predefined waypoints along my flight.

I really wish that it was possible to take pictures without interrupting a video to do so.

Are there any limitations in Orbit mode for the maximum radius? For example, could I mark the center point of the island and then set a radius of 1200m ? I think the DJI Go version had very low maximums for radius.

Last questions for now. In follow mode using an Airspace object as my leader. If the leader happened to be 5km away from me and the drone when I clicked "engage" - what would happen?

Would the drone take off and try to catch up to the leader - getting as fas as it could until it either:
a) caught up
b) lost connection with the remote
c) low battery triggered RTH?
(The above is what I would expect - but is my understanding correct or have I missed something?)

I'm also pretty scared to fly any missions that might lose connection with the remote (in my area, that can be as short as 450m) because of the DJI SDK bug that is mentioned on your website. Can you please explain the problem if different words (cuz I'm not 100% sure I understand the issue) and can you please also provide advice describing the best course of action for a pilot to take if they find themselves in that situation?

I do really appreciate you takin the time to participate in some of these threads! It's awesome to see answers coming from the company itself! If you've been monitoring all the threads that mention Autopilot, you'll notice that I've been a pretty vocal proponent of the Autopilot software ever since I purchased it 2 weeks ago. It's so much more advanced than what comes "out of the box" and I love what I can do with it now - and I'm looking forward to seeing how you guys decide to extend the capabilities going forward. What I'm most looking forward to in the way of enhancements are:

1. Arena Mode/Terrain Mapping for obstacle avoidance/safe flying within a defined zone (I emailed a description of this super-awesome feature request)
2. Waypoint actions as described above
3. Persistent Airspace object definitions and easier initial calibration
4. A mode that can take advantage of my Sony 3D glasses (HMZ-T3W) with some sort of VR or 3D display mode - Litchi and FPV advertise something like this
5. Advanced tutorials and maybe even exercises for the student to do to gain familiarity and confidence with the software.
6. Flight records that can populate the DJI "flight records" table so that I have a complete history of all flights I make regardless of the software I used

Thanks again

 

[Hangar]

Are you saying that I would not be able to maintain the 275 degree aircraft yaw through the remainder of the flight or are you saying I wouldn't be able to alter the strategy until the connection was re-established? The island doesn't have a flat shoreline and I've used waypoints to fly nice curves paths in and out of each bay. So given that that camera focus is accomplished by yaw on the Phantom 3 (the vertical angle is fine as a constant -15degrees) - what would happen to the existing yaw of the aircraft when connection was lost? Would it just start flying nose-forward towards the next waypoint - or does it remember the last orientation and maintain it?

The DJI SDK supports interpolated aircraft yawing between waypoints, so the yaw would still work. What would not work is the gimbal pitch. If the distance between the focus subject doesn't change, or the aircraft altitude doesn't change, or you are using a fixed pitch, then you are fine. Otherwise the subject will go out of frame along the z-axis. This is an SDK limitation and any app that supports LCMC will be affected by this, AFAIK. To be clear, LCMC is not possible in Autopilot presently, so this is a hypothetical conversation about what the feature would look like if we did implement it (given the SDK limitations).

As for waypoint actions - I'd like to be be able to do a panorama, and/or 2 orbits (1 for video and the second for photos) at certain predefined waypoints along my flight.

We are considering adding more waypoint action types (beyond hover) such as vertical booms, panos, and orbits. This functionality will not be in the next release, however. The full list of features coming in 3.3 is listed in the changelog.

I really wish that it was possible to take pictures without interrupting a video to do so.

This is a hardware limitation.

Are there any limitations in Orbit mode for the maximum radius? For example, could I mark the center point of the island and then set a radius of 1200m ? I think the DJI Go version had very low maximums for radius.

Yes, the radius is limited by the Max Distance settings under both Destination Parameters and Mode Controls settings sections. Both allow for very large settings.

Last questions for now. In follow mode using an Airspace object as my leader. If the leader happened to be 5km away from me and the drone when I clicked "engage" - what would happen?

Follow Mode, like all other computer and combined flight control Modes uses the idea of a target destination. As long as the target destination is within the bounds of the Max Distance Movement and Destination parameters (similar to the discussion above on the orbit), then Autopilot will obey the command.

Would the drone take off and try to catch up to the leader - getting as fas as it could until it either:
a) caught up
b) lost connection with the remote
c) low battery triggered RTH?
(The above is what I would expect - but is my understanding correct or have I missed something?)

Yes, assuming it is within the limits.

I'm also pretty scared to fly any missions that might lose connection with the remote (in my area, that can be as short as 450m) because of the DJI SDK bug that is mentioned on your website. Can you please explain the problem if different words (cuz I'm not 100% sure I understand the issue) and can you please also provide advice describing the best course of action for a pilot to take if they find themselves in that situation?

It is about risk management at the time. If you know your mission is likely to lose connection, then don't fly that mission with Autopilot. If you do lose connection, attempt to close the distance between you and the aircraft as fast as possible to reestablish connection.

I've been a pretty vocal proponent of the Autopilot software ever since I purchased it 2 weeks ago.

Thanks for the support!

1. Arena Mode/Terrain Mapping for obstacle avoidance/safe flying within a defined zone (I emailed a description of this super-awesome feature request)

This one is tricky as it represents a liability issue, in addition to a ton of code.

3. Persistent Airspace object definitions and easier initial calibration

Not sure how this would make the calibration process easier, but in the end altitude calibration is critical and we don't want to allow people to gloss over it.

4. A mode that can take advantage of my Sony 3D glasses (HMZ-T3W) with some sort of VR or 3D display mode - Litchi and FPV advertise something like this

Is this a gimmick or would you actually use it on a regular basis?

5. Advanced tutorials and maybe even exercises for the student to do to gain familiarity and confidence with the software.

Would you be willing to be for additional training material? The videos and documentation are very resource intensive in terms of production.

6. Flight records that can populate the DJI "flight records" table so that I have a complete history of all flights I make regardless of the software I used

We have been asking DJI to add support for this for a while.

 

[Tenly]

3.
a) Persistent Airspace objects
b) Easier calibration

Not sure how this would make the calibration process easier, but in the end altitude calibration is critical and we don't want to allow people to gloss over it.

3a and 3b were meant to be 2 separate things. 3a would allow me to fully prepare a flight plan in advance because the software would know about the Airspace objects and let me use them in my flight definition. As things are now - any part of my flight plan that uses an Airspace object can't be done in advance because the Airspace object doesn't exist.

3b - easier calibration - I don't understand why I have to bring the aircraft down to the same level as the phone. The aircraft was on the ground moments earlier. Did it not save a barometer reading at the time? I would think that calibration could be accomplished by saying "Place the iPhone on the ground at the point the aircraft took off from and press okay." That would save the barometer reading for 0 altitude and could be used for calibration - couldn't it?

4. 3D VR Flying

Is this a gimmick or would you actually use it on a regular basis?

I honestly don't know until I try it. I assume that with only a single camera on the drone, true 3D would be impossible - so in that case - maybe just a gimmick....

5. More robust training materials

Would you be willing to be for additional training material? The videos and documentation are very resource intensive in terms of production.

If they were comprehensive and robust - yes. If it were mostly just a re-hash of what already exists - maybe not. If they were offered for free it might translate to more sales of the app. One of the only problems with it in its current state is that it is less intuitive than some of the others. I understand that simplicity must be sacrificed in order to provide the flexibility that you do - and I'm not complaining. I think you've addressed it very well by using the "basic", "intermediate" and "advanced" tabs to hide the extra complexity until it is needed.

 

[Ibmftw]

You are absolutely correct of coarse, Litchi CANNOT change gimbal pitch during autonomous flight, was restricting this coded in on purpose on DJI end or just left out accidently, or is their a problem implementing it, what I am asking is are we ever going to see this function? @autoflightlogic

 

[Hangar]

3a and 3b were meant to be 2 separate things. 3a would allow me to fully prepare a flight plan in advance because the software would know about the Airspace objects and let me use them in my flight definition. As things are now - any part of my flight plan that uses an Airspace object can't be done in advance because the Airspace object doesn't exist.

That is correct. The question is, if we allowed you to pre-select an airspace object before it was connected, what should the behavior be if you engage Autopilot and that object is still not connected?

3b - easier calibration - I don't understand why I have to bring the aircraft down to the same level as the phone. The aircraft was on the ground moments earlier. Did it not save a barometer reading at the time? I would think that calibration could be accomplished by saying "Place the iPhone on the ground at the point the aircraft took off from and press okay." That would save the barometer reading for 0 altitude and could be used for calibration - couldn't it?

It depends on your mission. If you are not planning to move or change altitude, then you don't have to bring the aircraft down. You can just answer Fixed Operator and then choose Takeoff Location as the altitude reference. Assuming you are planning to change location and you want to lock in a reference altimeter (the iPhone's barometer), the safest course of action is to force the user to confirm that the two devices (the aircraft and iPhone) are currently at the same altitude during the calibration. Part of the issue with your suggested approach is that Autopilot may or may not be running when the aircraft takes off, so it doesn't always know the take off GPS coordinate. Furthermore, even if it does know the take off coordinate, how close is close enough? 5m? 15m? There could be other factors such as taking off from the bow of a boat and then going up to the bridge (10m higher for example). If you engage from the bridge, which is within some tolerance laterally (say 5m), you could end up with an incorrect offset, even though you are at the "same" location. Ultimately, the number of possible scenarios balloons pretty quickly when you think about it. We could give people the choice, but the problem is it would create yet another question that someone has to think about, possibly get confused about, and then answer, and if they answer it incorrectly it could result in a crash (nothing is more critical than the altitude calibration).

I honestly don't know until I try it. I assume that with only a single camera on the drone, true 3D would be impossible - so in that case - maybe just a gimmick....

Very few people have requested this feature, so it is currently low priority. With the current level of tech it seems more like a gimmick.

If they were offered for free it might translate to more sales of the app.

Of course, and this is why we offer the current documentation and videos for free, unlike some of the other apps out there.

 

[welly]

I would if I could. but just so I could turn around and buy it from a different vendor, instead of direct from DJI.

 

[Tenly]

That is correct. The question is, if we allowed you to pre-select an airspace object before it was connected, what should the behavior be if you engage Autopilot and that object is still not connected?

It would display an error message "Airspace Object Not Connected" and refuse engage until the problem was corrected.

As for the calibration discussion - I understand all of your concerns about the Airspace object calibration and i thank you for laying them all out. I think it would alleviate my issue and be a reasonable compromise if you simply provided the opportunity for me to calibrate it "on demand" - at my convenience - instead of tying the calibration to the engage sequence. That way, I could calibrate the 2 devices at the beginning of my flight - and it would remain valid for the entire flight. If the Airspace object was not calibrated prior to the engage button being pushed - the existing process would take care of it. Does that make sense? Are there any issues with doing that that maybe I haven't thought through?

 

[Hangar]

I think it would alleviate my issue and be a reasonable compromise if you simply provided the opportunity for me to calibrate it "on demand" - at my convenience - instead of tying the calibration to the engage sequence. That way, I could calibrate the 2 devices at the beginning of my flight - and it would remain valid for the entire flight. If the Airspace object was not calibrated prior to the engage button being pushed - the existing process would take care of it. Does that make sense? Are there any issues with doing that that maybe I haven't thought through?

You can already do this by starting the engage sequence, finishing the calibration, but then cancelling out of the dialog before continuing at the take-off screen.

 

[Tenly]

You can already do this by starting the engage sequence, finishing the calibration, but then cancelling out of the dialog before continuing at the take-off screen.

Okay. If you're saying that by doing that - it will remember the calibration for my entire flight - then I suppose that's good enough. I thought of doing what you suggested but then I convinced myself that it wouldn't remember it and just ask me again when j re-engaged.

Hey - I can't find the post I'm looking for now - but you mentioned something about restrictions when flying at negative altitudes. I wasn't aware that there were any such restrictions. What are the actual restrictions and what happens if you attempt to exceed them? Are these behaviours/restrictions put in place by Autopilot or by DJI? I'm picturing myself standing on the top of a cliff and taking off. It's entirely likely that I would want to fly to the bottom - so if you could provide some detail around these limits, I'd be very grateful....

 

[Fast13]

Wish I could return it. It's fast but not nearly as easy to fly precisely or smooth in sport and P is too **** slow. The battery BS is crazy too. Who actually cares about collision avoidance anyway? Okay. Yes in certain situations but not 98% of the time. It goes from porky pig mode to ludicrous mode with nothing in the middle. Very annoying. It also seems like I see the props a LOT more because it's so aggressive. I use my P3P more...

 

[Hangar]

What are the actual restrictions and what happens if you attempt to exceed them? Are these behaviours/restrictions put in place by Autopilot or by DJI? I'm picturing myself standing on the top of a cliff and taking off. It's entirely likely that I would want to fly to the bottom - so if you could provide some detail around these limits, I'd be very grateful....

The app won't let you specify altitudes less than 1m (our restriction), but that is relative to your altitude reference. If you engage Autopilot while in the air, you are given the choice to use the current aircraft altitude as "ground level", which means you can fly down into a valley and then calibrate there. All altitudes will then be relative to that altitude, which is below you.

 

[Tenly]

The app won't let you specify altitudes less than 1m (our restriction), but that is relative to your altitude reference. If you engage Autopilot while in the air, you are given the choice to use the current aircraft altitude as "ground level", which means you can fly down into a valley and then calibrate there. All altitudes will then be relative to that altitude, which is below you.

All Altitudes? Does that include the RTH altitude and the Max Height altitude? Or are they special?

There was a DJI firmware release today. Does that eliminate the problem with lost connections in Autopilot which were supposed to be fixed in "the next version" or the DJI firmware? (I didn't see anything in the release notes that indicated that it did)