Reason for flyaway
- Thread starter BlackTracer
- Start date
dalebb said:
Atti is half manual.
Atti has NAZA IMU assistance. So balance and height (vertical) is still computer assisted. You will notice its very difficult to brake and change direction as inertia is a *****. Be very sensitive on the sticks.
In manual, its all you. If the phantom is not well balanced, it will lean in that direction. There is no trim settings to counter it either. And did I mention it drops like a rock?
SteveMann said:I postulated this exact theory a few months ago. But even in ATTI mode, the "return to fence" is still working and has priority. Manual is the only way to save the Phantom if this happens.BlackTracer said:
Roger that. The chart shows you are right that manual mode is our only escape.
So it seems if we absolutely confirm home position is correct, this and many of the other fly aways become a none issue. Sounds like a step needs to added to standard startup before flying. So far I am leaning toward that step being looking at radar to verify HL is next to drone icon, and touch center to change to cell phone location, and verify it too is where you are. Seems if you do this then incorrect HL becomes a mute point. Sounds like a simple step to add. Do you agree?
yorlik said:
Yes. With Naza-M mode, launch the drone as normal and send it about 100 feet away, intentionally rotate it. Flick switch 2 down to the bottom and pull back on the right stick....ensure it comes back towards you..... It takes a few seconds to do this and ensures the drone won't go shooting off in some random direction if you lose signal with the controller etc.
I had to change the balance in assistant when I took the cam off to send it in for repair. I noticed it was not flying right.Mako79 said:
jonstatt said:
seems doing that MAY be too late and it will fly away..... again, if there is any validity in the concept that home pos. is sometimes set way off, then your method will loose it if the home pos is already outside the max diam fly zone. I think home pos needs to be checked BEFORE taking off..... I just flew this afternoon and home location seems to have been set 600' from where I was according to radar... I think radar and where-is-my-drone needs to be checked FIRST?
yorlik said:
No, that's why I said switch 2 and not switch 1. If you switch 2 right down that is IOC home lock. If you press down on the controls and it moves in the wrong direction, you just let go and it stops moving and stays where it is. If you bring switch 1 down after having set it to RTH, that would be the scare scenario you just described
not my point either. If you have max radius set to say 5000 ft in assitant, and home location pops up erroneously (as is not so uncommon on a non moving device) at 6000 ft away, as SOON as you fly up it will head BACK to within the allowable radius and be GONE. You will not have a chance to do s2 and test as it will GO.
Now...how different is all this looking to the official DJI procedure above ?
Little wonder people have problems like flyaways eh..
What do we (appear to) have at this point?
1. Power on and calibrate compass
2. Wait for 2 sets of rapid green flashes to indicate GPS lock.
3. Power-off and back on to reset elevation to something more like zero
4. Wait for step 2 above to repeat then take off and manually set the home point at an elevation of around 20m
Methinks a proper instruction guide with factual real-world instructions needs to be compiled !
Little wonder people have problems like flyaways eh..
What do we (appear to) have at this point?
1. Power on and calibrate compass
2. Wait for 2 sets of rapid green flashes to indicate GPS lock.
3. Power-off and back on to reset elevation to something more like zero
4. Wait for step 2 above to repeat then take off and manually set the home point at an elevation of around 20m
Methinks a proper instruction guide with factual real-world instructions needs to be compiled !
Attachments
yorlik said:
I tried to have a very similar conversation to this in this post: viewtopic.php?f=27&t=28149&p=286441#p286441. I got hammered pretty hard for theorizing about the Flight Controller (FC) GPS indicating an incorrect position (drone is actually at point A, but GPS says it's at point B, an unknown distance from point A), and the HP being set while the GPS is pointing to this incorrect GPS location. If after setting the HP to this incorrect GPS position, the GPS then "tightens up" and starts indicating a correct GPS location (drone is at A, and GPS indicates its at A), when the drone lifts off the FC will immediately detemine drone to be a distance from the HP equal to the distance between points A and B. If that distance puts the drone outside its flight limits geo-fence, it will immediately fly toward the HP until it gets back into that area defined by the flight limits. While this may be thought of as a fly-away, it is in no way a malfunction. This is absolutely correct flight controller behavior according to its theory of operation. The problem that needs fixed is not the drone flying away, its the HP being unknowingly being set to an unknown GPS location other than where it is about to take off from.
"So it seems if we absolutely confirm home position is correct, this and many of the other fly aways become a none issue. Sounds like a step needs to added to standard startup before flying."
I think this nails it. It's actually where my original post was going... a way to positively confirm where the drone is at, according to the drone's FC GPS system, at the time the HP is set. I was talking about using a Flytrex Live 3G unit as a tool to do exactly this. I have since installed one, and it works perfectly. I integrated a visual GPS position verification into my pre-flight and take-off checklist procedures, and when I set the HP (both automatically at first motor start, and manually), I'm looking at the GPS position my drone's FC is seeing plotted live on GoogleMaps, via the Flytrex Live flight page. As best as is posible, I positively KNOW the GPS position that my HP is set to is the same as my launch point before I launch. Works great.
It's important to note this only works if you are viewing the actual FC GPS system, not a seconday GPS system. Secondaries show you their GPS position, not the GPS location the FC used to set the HP. The Flytrex unit taps directly into the FC GPS, showing you the same GPS data the FC is using.
You also need to realize GPS posiition accuracy can fluctuate dramatically as the FC locks and looses satellites. Here is a screen-shot of a 5-min tied-down test flight I did inside my home. The drone never moved. During this time I bounced from good satellite lock to bad lock a few times. Just because the drone is sitting right there where it had good sat lock a minute ago does not mean the GPS is still indicating that's where it is. This is why I want to SEE where the FC GPS says the drone is at when I set the HP.
Attachments
I personally feel the GPS location theories don't cover the majority of these fly-aways, wouldn't you see 'Returning Home' on screen?
I think the phantom is loosing the control signal due to interfrence and then responding incorrectly to rouge commands, if it is bad enough S1 commands won't get through. It should however RTH when it hits the distance limit, perhaps that is where the bug is when the phantom is doing crazy things responding to rouge signals.
I think the phantom is loosing the control signal due to interfrence and then responding incorrectly to rouge commands, if it is bad enough S1 commands won't get through. It should however RTH when it hits the distance limit, perhaps that is where the bug is when the phantom is doing crazy things responding to rouge signals.
Thank you Chuck. I was believing the same - until packetlos just now made his comment.... Packetlos, you make a GREAT counter point.... Now I am more confused than ever!
Chuck, I looked at your referenced thread. Wow. I am sorry you got the same negative crap I recently also got for my ideas. Too bad some folks here have no open minds to consider alternative ideas. I too will be stopping posting as some of the folks on here are real sh1theads, and I don't need it. If they do not want my ideas, so be it. See you later. Thank you very much for posting!
Chuck, I looked at your referenced thread. Wow. I am sorry you got the same negative crap I recently also got for my ideas. Too bad some folks here have no open minds to consider alternative ideas. I too will be stopping posting as some of the folks on here are real sh1theads, and I don't need it. If they do not want my ideas, so be it. See you later. Thank you very much for posting!
packetlos said:
That's a very good point. You might be correct, but I don't know. However, the scenario I presented is not a true RTH. It's actually a state of the flight controller finding itself outside its defined flight boundaries, and this triggering a return to the designated flight area, where it returns control once it gets back inside its limits, not a RTH for landing, where it would display "Returning Home". I don't think this scenario would display "Returning Home", but it might be that it should display "Distance Limit Reached". However, in reading the manual, I can't say I understand whether it would or not in this scenario.
The manual discussion of flight limits confuses me a bit. In one place it states that in Ready To Fly (non-GPS) mode there are no limits for Max Radius. Yet right below that there is a bullet statement indicating if you fly out of the Max Radius in Ready To Fly (non-GPS) mode, it will fly back into range automatically. That clearly seems like a an actively monitored limit to me. Am I ready that wrong? In reading the left panel of the screen shot from the Assistant Software where you set the limits, it appears to be saying when in Ready to Fly (GPS) mode, if it get out of the limits, you only have throttle and rudder control, and it will automatically return to the defined area (not all the way to the HP). It states in a couple places that Max Radius does not apply to non-GPS mode, so I have to assume it's a typo where it says non-GPS mode will return to within the limits.
Regardless, you may be correct in that a message could be displayed that would tell us it sees itself outside its flight limits. Has anyone ever flown past the Max Radius and seen the message displayed? Might be an interesting flight test someday.
Thanks for questioning it... nice to have a real discussion on it.
Also... you are most certainly correct that this scenario does not account for a majority of fly-aways. The very scenario limits itself to fly-aways that take place right after lifting off. But, if it accounts for any flyaways, and I can do something to prevent it from happening to me, it's time well spent in my flying program.
Attachments
This may have already been mentioned. I didn't read every post in the thread.
But...
In the Vision APP, pay attention to the Distance reading at the bottom next to the radar.
N/A means it has not set home point yet.
0 M or 0 Ft means it's on the home point. My checklist includes swiping into the ground station view to verify the home point and current location are on the map where I am.
Usually it's difficult outdoors in bright sunlight to watch the tail lights carefully. IMO it's virtually impossible to keep my eyes on the lights the whole time when I'm trying to go through the checklist and other people are around.
This will be somewhat academic when the next firmware is released as the app will warn you and prevent launch if home point has not been set.
I'm certain this is in direct response to DJI investigating the causes of flyaways and crashes.
They surely know much more about the various causes than we do and they are working on improving the software to help prevent these user errors which I'm sure cost them a lot of money.
When the Inspire 1 had several reported crashes with no pilot error, DJI used the Inspire's logged data to determine the cause was bad IMU calibration so they updated the app to warn the pilot and prevent takeoff if the IMU requires calibration. This update should also make it into the next Phantom 2 Vision/Vision + firmware also, so we benefit from the additional logging and reporting DJI added to the Inspire.
Any interference might block the control signal but there could be no rogue commands unless someone has captured and is deliberately spoofing your transmitters unique ID.
It would be trivial to capture a transmitters ID code since it is broadcast every time you turn on the transmitter, but I think that scenario is an unlikely cause of any significant number of fly away events.
But...
In the Vision APP, pay attention to the Distance reading at the bottom next to the radar.
N/A means it has not set home point yet.
0 M or 0 Ft means it's on the home point. My checklist includes swiping into the ground station view to verify the home point and current location are on the map where I am.
Usually it's difficult outdoors in bright sunlight to watch the tail lights carefully. IMO it's virtually impossible to keep my eyes on the lights the whole time when I'm trying to go through the checklist and other people are around.
This will be somewhat academic when the next firmware is released as the app will warn you and prevent launch if home point has not been set.
I'm certain this is in direct response to DJI investigating the causes of flyaways and crashes.
They surely know much more about the various causes than we do and they are working on improving the software to help prevent these user errors which I'm sure cost them a lot of money.
When the Inspire 1 had several reported crashes with no pilot error, DJI used the Inspire's logged data to determine the cause was bad IMU calibration so they updated the app to warn the pilot and prevent takeoff if the IMU requires calibration. This update should also make it into the next Phantom 2 Vision/Vision + firmware also, so we benefit from the additional logging and reporting DJI added to the Inspire.
That's virtually impossible. The control signal is spread spectrum and bound to a specific transmitter with a unique encryption code.packetlos said:
Any interference might block the control signal but there could be no rogue commands unless someone has captured and is deliberately spoofing your transmitters unique ID.
It would be trivial to capture a transmitters ID code since it is broadcast every time you turn on the transmitter, but I think that scenario is an unlikely cause of any significant number of fly away events.
Don't discount the possibility of equipment failure in a significant percentage of fly aways.
The flight controller is a computer and computers can crash or glitch causing unpredictable behavior.
The GPS module can stop working or even fail in such a way that it's calculating the wrong position which could be hundreds of miles off from where it is.
(Hence the ground station preflight check)
No doubt pilot error is the leading cause. Equipment failure is probably a small percentage of fly aways but they happen.
The flight controller is a computer and computers can crash or glitch causing unpredictable behavior.
The GPS module can stop working or even fail in such a way that it's calculating the wrong position which could be hundreds of miles off from where it is.
(Hence the ground station preflight check)
No doubt pilot error is the leading cause. Equipment failure is probably a small percentage of fly aways but they happen.
