Posted by Paul Mather on September 15, 2009 at 6:30pm
I dropped the "Beta 4" and changed it to just v1.4 revision 12 = 1.4.12.This version has a bug fix to try and address users with locales using "," (comma) as their decimal points. Please let me know how it works. It also includes Jordi's 48 waypoints fix.Download Here: ConfigTool.zip
It's not too many lookups, I just think it may be a bit out of the scope of the project. The "over terrian" checkbox may be too confusing as it is. It might make more sense to warn the user that they'll be within X feet of the ground on a segment. But again, I think that's outside the scope of the project for now.
You would have to do a data lookup for the points in between, since you are getting the terrain height back as part of the query, check the ground height in comparison to the current 2 points ground heights. We know the Altitude to hold(AGL) so if the altitude is more than say a percentage(50% or what ever) of the Altitude to hold (AGL reduced by whatever % we selected) we have a new waypoint at that point.
Hope the above is clear. It may mean too many lookups or too much processing though.
Hi fefenin
I carried out the procedure you suggested with V1.4.12. The home position read worked perfectly after the D6 bind and after a read when I moved the map home a short distance. As far as I can tell, the problem is solved. Thanks Happy
That's exactly what I'm talking about. I have two points. Between those two points are multiple peaks and valleys. What criteria do I use to determine it needs an auto-waypoint?
I've been doing some thinking on the max altitude between two waypoints. I'd have to create another non-draggable marker called an "Auto-Waypoint." It would be dynamically created as new points are added or "real" waypoints are dragged. The toughest part would be trying to follow the line mathematically and at some regular interval query the altitude. Then there would be the question of where should I place an auto-waypoint?
Let's say the user added a waypoint on the West side of a mountain range. Then added a second waypoint on the east side of a mountain, 2 mountains over. So now it would go WP#1, peak #1, valley, peak #2, WP#2. Let's say the math showed that peak #2 was the highest altitde in the line between WP's, but peak #1 was only 1 foot shorter. It's entirely possible that the flight path could take the plane into the first mountain. Does that make sense? I think this is too much logic for the configuration tool to figure out.
I just tried it and confirm that home set by GPS is read properly. Home is orange and where it's supposed to be. "set manually" not checked, of course.
Comments
You would have to do a data lookup for the points in between, since you are getting the terrain height back as part of the query, check the ground height in comparison to the current 2 points ground heights. We know the Altitude to hold(AGL) so if the altitude is more than say a percentage(50% or what ever) of the Altitude to hold (AGL reduced by whatever % we selected) we have a new waypoint at that point.
Hope the above is clear. It may mean too many lookups or too much processing though.
Rgrds
Sarel Wagner
I carried out the procedure you suggested with V1.4.12. The home position read worked perfectly after the D6 bind and after a read when I moved the map home a short distance. As far as I can tell, the problem is solved. Thanks Happy
Rgrds
Sarel Wagner
Let's say the user added a waypoint on the West side of a mountain range. Then added a second waypoint on the east side of a mountain, 2 mountains over. So now it would go WP#1, peak #1, valley, peak #2, WP#2. Let's say the math showed that peak #2 was the highest altitde in the line between WP's, but peak #1 was only 1 foot shorter. It's entirely possible that the flight path could take the plane into the first mountain. Does that make sense? I think this is too much logic for the configuration tool to figure out.
did you try to move "home" placemark and read again read ??
@joseph
thank you for this explaination: "said that the google plot home(mark) would not be refreshed for some reason having to do with gooolgle"
when i'm talking about "home " as i already said, i'm talking about home placemark and not "Home Info " displayed on the left hand side
"Home Info " displayed on the left hand side doesn't refresh eitheir for me... (i'm not sure about it so i'll check again )
the only way i found to be sure to have stored "home " the right place is to check the ardiplot serial output at bootup
i agree that it is already very usefull soft!!
it already works as it and all the time in fact, sure it is a minor bug!!
don't break you brain on this, it is not that bad
regards
fefenin
So I'm not seeing any problems at all.