P3P controller range limits

[Yeager74]

Sorry missed that bit. We have done this exact thing and the RTH did execute, but we will test it again tomorrow.

Sounds good, thanks. I will likely go out and test a couple of different scenarios/modes today as well.

 

[Yeager74]

Sorry missed that bit. We have done this exact thing and the RTH did execute, but we will test it again tomorrow.

Hi @autoflightlogic ,

My apologies for the extensive reply;

So, today, I conducted further operational flight tests of the P3P failsafe operations, with both DJI GO (iOS) app. and the Autoflight Logic Autopilot (iOS), in separate events. DJI App 2.5.1. Aircraft 1.6.40, RC 1.5.70. Autopilot 3.0.

In order to test the Remote Control (RC) signal loss, I completely switched off the RC power and left it off for a minimum of 20+ seconds, in all tests. The aircraft was positioned at a lateral distance of more than 20 meters away from both the Home Point and the Radio Control and in F-mode (Function/IOC).

Observations of Plane behaviour:

DJI GO – Waypoint (with return to home after mission completed, selected) = Completed waypoint mission, then Failsafe RTH
DJI GO – Home Lock = Failsafe RTH
DJI GO – Course Lock = Failsafe RTH

AUTOPILOT – ORBIT = Hover in position, with NO failsafe RTH
AUTOPILOT – WAYPOINT (with return to home after mission completed, selected) = Hover in position, with NO failsafe RTH

In the Autopilot V3.0, waypoint and orbit mode, the plane would stop at its current position (at the time of RC signal loss) and hover, it would NOT execute the RTH function. I’m not sure what happens when the intelligent battery would reach its low battery level failsafe point, as I did not carry out this test, but I will test this at first opportunity.

After reviewing the Autopilot flight logs on healthydrones.com, it would appear that the “home point” location changes from the original “home point’ location, recorded via the DJI GO application (as Auto Flight Logic advises in the Flight School Tutorial), to a new “home point” location at some point when the RC signal was lost/OR/RC signal re-established.

See PDF no 1., as reference to the engagement of waypoint mission and RC signal lost (RC power off).
See PDF no 2, as reference to when RC signal was recovered (RC powered back on).

After re-establishing RC signal, the plane would remain in hover at its current position, until manually pressing the RTH button on the RC, after which the plane returns to the original “home point” location (as recorded via the DJI GO application). So it seems that the “home point” location stored in the plane remains the original location, and not the “new” “home point” location as shown in healtydrones.com.

I’m wondering if the Autopilot V3.0 uses this “new” home point location as some kind of reference, and therefore hovers instead of RTH (original location), that would overrule the original home point location, and if this is what causes it to NOT execute failsafe RTH (original). I doubt it, just wondering.

Anyways, in the case of my combination of the P3P and the Autopilot V3.0, at least in waypoint and orbit mode, the plane does NOT failsafe return-to-home on RC signal loss, but hovers in current position, until hopefully an RC signal is re-established and the manual RTH command is received by the plane.

That's it for now.

 

[Wurzel]

Hi @autoflightlogic ,

My apologies for the extensive reply;

So, today, I conducted further operational flight tests of the P3P failsafe operations, with both DJI GO (iOS) app. and the Autoflight Logic Autopilot (iOS), in separate events. DJI App 2.5.1. Aircraft 1.6.40, RC 1.5.70. Autopilot 3.0.

In order to test the Remote Control (RC) signal loss, I completely switched off the RC power and left it off for a minimum of 20+ seconds, in all tests. The aircraft was positioned at a lateral distance of more than 20 meters away from both the Home Point and the Radio Control and in F-mode (Function/IOC).

Observations of Plane behaviour:

DJI GO – Waypoint (with return to home after mission completed, selected) = Completed waypoint mission, then Failsafe RTH
DJI GO – Home Lock = Failsafe RTH
DJI GO – Course Lock = Failsafe RTH

AUTOPILOT – ORBIT = Hover in position, with NO failsafe RTH
AUTOPILOT – WAYPOINT (with return to home after mission completed, selected) = Hover in position, with NO failsafe RTH

In the Autopilot V3.0, waypoint and orbit mode, the plane would stop at its current position (at the time of RC signal loss) and hover, it would NOT execute the RTH function. I’m not sure what happens when the intelligent battery would reach its low battery level failsafe point, as I did not carry out this test, but I will test this at first opportunity.

After reviewing the Autopilot flight logs on healthydrones.com, it would appear that the “home point” location changes from the original “home point’ location, recorded via the DJI GO application (as Auto Flight Logic advises in the Flight School Tutorial), to a new “home point” location at some point when the RC signal was lost/OR/RC signal re-established.

See PDF no 1., as reference to the engagement of waypoint mission and RC signal lost (RC power off).
See PDF no 2, as reference to when RC signal was recovered (RC powered back on).

After re-establishing RC signal, the plane would remain in hover at its current position, until manually pressing the RTH button on the RC, after which the plane returns to the original “home point” location (as recorded via the DJI GO application). So it seems that the “home point” location stored in the plane remains the original location, and not the “new” “home point” location as shown in healtydrones.com.

I’m wondering if the Autopilot V3.0 uses this “new” home point location as some kind of reference, and therefore hovers instead of RTH (original location), that would overrule the original home point location, and if this is what causes it to NOT execute failsafe RTH (original). I doubt it, just wondering.

Anyways, in the case of my combination of the P3P and the Autopilot V3.0, at least in waypoint and orbit mode, the plane does NOT failsafe return-to-home on RC signal loss, but hovers in current position, until hopefully an RC signal is re-established and the manual RTH command is received by the plane.

That's it for now.

Thanks for the research and valuable information.

 

[happydays]

I have a P3P. I have been doing pretty well with DJI Pro and Autopilot 3 (which is awsum). But I have been flying waypoint loops of as much as a couple of miles around. As I am in the center with the controller I have full telemetry and control.

My question here is simple but I bet the answer isn't. If I choose a route that takes the craft beyond telemetry and RC limits, will the craft continue to execute the flight plan until it reaches some further point. For instance I imagine following a famous salmon river with hundreds of small boats on it for as far as 7 miles. In Autopilot one engages the program after liftoff at say twenty feet and it executes the plan. Would the craft also continue that plan. If it went beyond range then settle down and land at the end waypoint. This so I could launch and drive there to wait for it.

I'm doing something similar to you, believe it or not.

My plan is to map the route of the oldest summit level canal in the British Isles from Lough Neagh to Carlingford Lough. There are points where a road runs alongside the canal, but at other times it runs inland and the closest access would be about half a mile away.

The Litchi came along - with pre-programmable waypoints and I thought this would be great because - it stores the mission and continues it until it is complete, control signal or not. So I did some testing to see if it would be viable. I launched the phantom by the sea, and had it fly a mission inland ending up above a big field beside my house. As it set off on the 10-minute mission, I jumped on the bike and went to the end point. And the phantom duly appeared and hung in the air when the mission was over awaiting command. Perfect! I can launch it at one point and drive to the pickup point!

So I know that that works. Now what I did was to plan all the missions on desktop, 14 in total, each one taking 12-13 minutes to allow me time to reach the end point safely and with enough in reserve in case of trouble with traffic (all rural roads, so no real issues).

One thing that you'll need to be very aware of is changes in height as the topography varies, especially with a salmon river. The phantom will need to be programmed to vary its height with the terrain as it only has take off point as a reference. So be very careful.

Apart from that, it's doable, but risky!

 

[Hangar]

Just tested this and here are the results:

• DJI GO
  • Turn off RC: RTH activated
  • Let battery drain to the critical battery threshold (in this case 15%): RTH activated
    
  • Press RTH button on RC: RTH activated
  • Press RTH button a second time on RC: RTH deactivated
• Autopilot
  • Turn off RC: RTH NOT ACTIVATED!
  • Let battery drain to the critical battery threshold (in this case 15%): RTH activated
  • Press RTH button on RC: RTH activated and Autopilot is overridden (Flight Dashboard displays RC Override)
  • Press RTH button a second time on RC: RTH deactivated and Autopilot resumes mission

Clearly the RC disconnect case in Autopilot should have activated RTH. Are you using the latest version of Autopilot (beta 3.1)? The new version of Autopilot uses the new SDK (3.0), so it is possible DJI introduced a bug. We are following up with them now.

DJI distributes a sample app with their SDK which has the same bug, so this is error is definitely not Autopilot specific, but rather SDK app specific. To be clear, this was not the behavior we saw when we previously tested it with SDK 2.4 (which is what Autopilot 3.0 was based on).

 

[Yeager74]

Hi @autoflightlogic ,

Are you using the latest version of Autopilot (beta 3.1)?

No, I'm not using the Beta version, I'm using the latest release of the Alpha version of Autopilot (version 3.0). Ultimately it's good that the unexpected and unwanted behavior has now been identified, so that it can be rectified as soon as possible. Thanks for your quick response in confirming the behavior.

It does remain a potential threat, to loosing a plane (or worse), until a ratification has been carried out, as most users of the waypoint mode are likely believing in the failsafe RTH function to be operationally safe, which after all is more likely to happen in that mode (waypoint) than any other mode.

Please advise as soon as possible when the failsafe operation within Autopilot is again operational. Your Autopilot application is in general a great tool, unfortunately it is not useful to me, because of the current bug, as identified.

 

[Jack Ley]

That is correct, as discussed here.
In the case you mention, it is possible that the RC had not completely lost connection, but rather the telemetry was just delayed. If this happened, Autopilot automatically brings the aircraft to a hover and displays an appropriate warning message on the flight dashboard.

I have a question then, that's pretty similar to this problem. I used waypoint program for the first time today and had some problems with it. First off, if I didn't have DJI GO closed, the phantom would take off and do a wide orbit type flight no where near the first waypoint. So once I figured that out, and launched again, the phantom followed the waypoints and focused pretty well on the focus triggers ( I had it set for 5 waypoints and 4 camera triggers, flown over an area about 10-15 acres) but at each waypoint it would stop, then fly back the way it came about 25ft or so, pause again, then continue on to the next waypoint. On one of the waypoints it did this twice. Did I set something wrong that would make it do that? Second question, all the missions I flew today I "engaged" with the phantom on the ground, letting Autopilot do an auto take off. I have seen several people say they only engage after they are in flight, should I switch to doing that?

 

[SDODD]

I have a question then, that's pretty similar to this problem. I used waypoint program for the first time today and had some problems with it. First off, if I didn't have DJI GO closed, the phantom would take off and do a wide orbit type flight no where near the first waypoint. So once I figured that out, and launched again, the phantom followed the waypoints and focused pretty well on the focus triggers ( I had it set for 5 waypoints and 4 camera triggers, flown over an area about 10-15 acres) but at each waypoint it would stop, then fly back the way it came about 25ft or so, pause again, then continue on to the next waypoint. On one of the waypoints it did this twice. Did I set something wrong that would make it do that? Second question, all the missions I flew today I "engaged" with the phantom on the ground, letting Autopilot do an auto take off. I have seen several people say they only engage after they are in flight, should I switch to doing that?

I believe early on I learned like DJI GO Autopilot needs to be airborne before engaging. I unusually expect to be at least 35 feet up. Were any of your points below that altitude? In many cases it complains below that and does not allow it to engage anyway. Also Autopilot can not only sense altitude in the craft but in some controller devices and does math on the differences. Obviously if it does not know the altitude of the device it assumes no change and that can get sticky in a follow-me mode. There is some line between iPhone versions for instance where below version 6s there is no native phone barometer. So there is an issue there about altitude behavior. I have the more advanced phone and the older iPad. They act so differently I always fly with the phone even if I develop plans on the iPad. So check that all out in the tutorial as you may be confusing your system. Autopilot has entry positions to adjust for steady or moving altitude and barometric correction. It is important you have that correct.

 

[SDODD]

I believe early on I learned like DJI GO Autopilot needs to be airborne before engaging. I unusually expect to be at least 35 feet up. important you have that correct.

Looking again I see that Autopilot will not engage below 16 feet. It also enforces altitude priority which measure differences in altitude and halts the craft upon minimums not being met. These taken together may produce some odd effects. Personally I think that if one fly's autopilot below that altitude he is going to crash very soon. There just isn't enough precision in the data to stay out of trouble. At a $1,000 a craft it makes little sense to get into that zone. Of course one can fly by hand and perhaps do better.

 

[Hangar]

I have a question then, that's pretty similar to this problem

Answered here.

Looking again I see that Autopilot will not engage below 16 feet.

You can engage Autopilot while sitting on the ground, and it will perform an auto-takeoff. The Minimum Altitude setting can be set as low as 0 ft, but by default it is set to 23 ft, meaning once it takes off, it will ascend above 23ft and not allow missions below that altitude (the hard deck).

 

[SDODD]

I did not realize this. But then I never tried it after reading it engages abortive 16 feet. Anyway Autopilot repeatedly points out that they give altitude priority to control and it is possible the craft may react suddenly to put distance between itself and the ground. I have had it go in and out of control while doing a follow me and it halted after half a mile 200 feet up. I turned and returned to the spot and it resumed following me back into range.