Kloo Gee
First Officer
Flight distance : 16783757 ft
United States
Offline
|
This is a fascinating discussion and something that I've had on my mind for quite some time when looking at the errors I see in all the logs I see on the forum. I'm what I like to call a technical idiot! I know just enough to think I know how everything works, but just not quite enough to know I am probably missing a key piece of knowledge that may make or break a theory. So here goes my thoughts:
First off, DJI needs to solve the root cause of compass error whether it is a software issue or a hardware issue. If they solve this, then most (but not all) of the reason for this discussion goes away.
Secondly, some very important assumptions:
1. Compass, GPS, and barometer are all needed for normal operations
2. Compass, GPS, and barometer are independent systems and can provide data to system independently of each other
3. Without a working compass, the aircraft doesn't know which way it is pointed
4. When a compass error occurs, DJI "chooses" to exit out of GPS mode and go to ATTI mode reading only barometer data to hold altitude.
5. DJI could "choose" to continue utilizing GPS data when compass experiences error, but "chooses" not to in current implementation
6. Compass is required to know what direction aircraft is facing when not moving
7. A home point GPS location has been recorded and stored on the aircraft
8. As a quad-copter, the aircraft can move in any direction regardless which direction it is facing unlike a fixed wing aircraft
9. When an aircraft loses connection with the controlling device, it should initiate an RTH after documented period of time has elapsed
10. RTH already has a documented procedure where it rises to a "safe" RTH altitude and returns to home with obstacle avoidance disabled.
Can we all agree on those assumptions?
-------------------------------------------
Based on all of my assumptions being true above, here is my theory of how the problem could be solved with only GPS and barometer working, but NOT the compass. I think a competetent programmer could make this work fairly easily.
With a known home point location marked in memory and the ability to get the current location of the aircraft with the working GPS system, the device can calculate how far away it is from the marked home point location. However, at this point, it doesn't know what direction to initiate movement in order to get itself closer. So at this point, it initiates a series of 4 to 8 small movements. These movements would be something like forward, backward, left, right, forward left, forward right, backward left, and backward right. After each of those small movements, it compares the new location with the home point and determines if it is now closer to the home point than it was previously.
Based on these movements, the aircraft would have a rough idea of which direction to fly in order to get to the home point. It could then calculate an imaginary line between the current location and the home point. It then would initiate flying in the direction it roughly determined was the home point. It then would recursively start asking itself, am I getting closer to the home point and am I staying close to the imaginary line that was calculated as the route home. If it is getting closer to home and staying within a given deviation of the line, then continue in that direction. If it is deviating off the line calculated for the route home, then adjust the course left or right as necessary to stay close to it.
Now, understand that in this scenario, the aircraft may not be coming back to the home point with its face towards the home point. But that doesn't matter at all, its not a fixed wing aircraft. It is a quadcopter, so it can fly fairly efficiently in any direction regardless of where it is "facing".
Also, using this method, North/South/East/West are pretty much irrelevant. Also, using this method, it accounts for any issues with the wind trying to push it off course.
If this procedure was invoked, it should rise to the RTH altitude setting and turn off obstacle avoidance in the same way that occurs if the aircraft is more than 100 meters away when an RTH is invoked.
If the compass system returns to normal while this procedure is in progress, then it should resume normal RTH procedures instead of this special "Compass Mode Error RTH mode".
Philosophically, the question is when to initiate this Compass Error Mode RTH procedure? Do you do it at the point today where the Spark goes into ATTI mode? Or do you do it at the point where the remote control loses connection AND you are in ATTI mode from a Compass error? I personally would recommend the latter, but might suggest an option in the menus to allow a user to choose.
Okay, so I put it out there, what am I missing? |
|