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.
The thing with software faults is they are usually discovered after its too late, the WEP wireless security protocool was once considered secure.
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.
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.
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.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.
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.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.
This is already coming in 3.3 starting with Waypoint Hover actions. See the full changelog here.the stopping to perform an action at each waypoint
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.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?
Yes and maybe a huge difference between your flying conditions and the the ones DJI had.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 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.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?
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 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
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.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.
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.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
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.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.
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.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.
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?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.
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.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.
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.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
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.without even slighly incenuating that your platform is better than the compettiors, speaks volumes anyway, I will be taking a look at your app.
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.
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).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?
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.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.
This is a hardware limitation.I really wish that it was possible to take pictures without interrupting a video to do so.
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.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.
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.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?
Yes, assuming it is within the limits.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?)
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'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?
Thanks for the support!I've been a pretty vocal proponent of the Autopilot software ever since I purchased it 2 weeks ago.
This one is tricky as it represents a liability issue, in addition to a ton of code.1. Arena Mode/Terrain Mapping for obstacle avoidance/safe flying within a defined zone (I emailed a description of this super-awesome feature request)
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.3. Persistent Airspace object definitions and easier initial calibration
Is this a gimmick or would you actually use it on a regular basis?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
Would you be willing to be for additional training material? The videos and documentation are very resource intensive in terms of production.5. Advanced tutorials and maybe even exercises for the student to do to gain familiarity and confidence with the software.
We have been asking DJI to add support for this for a while.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
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.
4. 3D VR Flying
Is this a gimmick or would you actually use it on a regular basis?
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.
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?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.
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).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?
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.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....
Of course, and this is why we offer the current documentation and videos for free, unlike some of the other apps out there.If they were offered for free it might translate to more sales of the app.
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?
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.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.
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.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.
We use essential cookies to make this site work, and optional cookies to enhance your experience.