SkyDemon Forums

How to set SD to follow a router segment creation-order during a live navigation

http://forums.skydemon.aero/Topic24355.aspx

By ane - 9/7/2017 7:06:24 AM

Thanks Tim,
‌I suppose for a general navigation, one won't have any segment of a route so close to each other, so the default algorithm might (and does) work well.

I'm asking for something that is not usual to do, I know. My question is on how to do that with the actuall configuration possibilities of SD.‌‌

Maybe if there is an option to force a lock on the zoom, then I would simply fly the little airplane . . . yet still have to know which segment comes next, and not mix it up.

Also, is it possible to place a remark (short note) on a leg, and have it (the note text) constantly drawn on the segment‌‌ during flight ? the same way as the course and segment length is shown (when you click on the segment), but this note would be visible all the time on all the segments... Then I would just place a upcounting set of numbers, one on each leg segment, and fly manually aligning to the actual number.

Just thinking out loud - and hoping to receive any hint that would help me out, even a little bit. Thanks in advance.‌‌
By ckurz7000 - 9/7/2017 7:58:01 AM

Could you define the four segments so that you always "land" at the center point. There would be four individual route segments and you could activate the appropriate one simpy by touching it on the screen.

-- Chris.‌‌
By Tim Dawson - 9/12/2017 9:00:53 AM

That's a good idea!

No it's not possible to hand-annotate routes in SkyDemon with your own text.

My only thoughts on this so far have been if there are multiple legs near your position (within a threshold distance) we attempt to use your ground track to disambiguate them. But this opens up possibilities of further errors.‌‌
By jfw - 9/12/2017 9:32:43 AM

Hello,

While  your example is extreme, I reported some time ago a similar issue (http://forums.skydemon.aero/Topic17302.aspx‌‌
The planned route is passing two times at the same point (entry and exit point for the EBBR exception to go to/from EBGB).‌

I see two (in my eyes) "easy" options:
‌-include some/better directional logic for the selection of the path (currently it even selects a path 180° of my direction)
-when in doubt and the selected leg could be the following one of your route, use this as preferred route.
I will try to clarify this: if you have the route AB-BC-CD‌‌‌-DE-EF and that for some reason the legs DE is close to the leg BC and there could be confusion is selecting the legs, I would assume that if your are flying AB the next would be BC while the next would be DE if you are flying CD.
The logic behind is that if you plan a route you could expect the be following the different legs in the order you planned these.
In the event you change your plans you can do a "route direct to turning point‌‌" in order to have amend your planned route.

A third option could be a "double-click to select segment as active‌" or something similar

Hope you understand what I mean.
Br,
J‌‌‌‌‌
By Tim Dawson - 9/14/2017 10:18:22 AM

The trouble is, we never, ever want the user to have to tell SkyDemon to advance to the next leg because we've got it wrong.
Even the notion of using the direction of travel to select the leg is flawed, because if the user performs an orbit, we will briefly select the wrong leg and advise they change their heading accordingly. Not good. ‌
By jfw - 9/14/2017 12:01:25 PM

Tim Dawson - 9/14/2017 10:18:22 AM
The trouble is, we never, ever want the user to have to tell SkyDemon to advance to the next leg because we've got it wrong.
Even the notion of using the direction of travel to select the leg is flawed, because if the user performs an orbit, we will briefly select the wrong leg and advise they change their heading accordingly. Not good. ‌

‌Good point for the orbit... I haven't thought about that one...  and I understand your position regarding the user being able to select the leg.
This leaves one option: in case of different options are possible select the one that  makes most sense vs what was planned.
Any comments or your view on this are more than welcome.

J‌‌‌‌‌
By Tim Dawson - 9/25/2017 12:31:52 PM

It's too complicated. If we were to add such an option the problem would then be, when does the software revert to automatic selection after the user's manual nomination of the active leg. Each of these actions would then need its own UI, and that UI would need to be tested and not add complication to the product (which it would). I'm definitely open to suggestions on this one but there may not be a way of doing it that we're happy enough to proceed. The existing implementation requires no intervention and works in nearly all "normal" cases which sets a very high bar.
By ane - 9/6/2017 6:46:29 AM

In a a live navigation (en route) navigation regime,
what is the configuration option to make SD stick to the preconfigured route segments in the true order of these,
and not to "randomly" skip to the segment which is closest to the actual position.

Have a look at the example route I'm flying (quite often, in fact):



Each router segment length is about 1 nautical mile, so there is enough separation
to see that each particular segment has indeed been flown (waypoint to waypoint, of course never exactly on spot).

When flying not exactly on course, or even just being close to the middle point,
the SD jumps to the closest route segment, but not to next logical route segment.
I have placed the segments in a right order, and it is even properly shown in the Pilot Log (and other places),
yet during the flight, the SD selects the segment it sees the most close.

So my question is - what is (and where is) the specific configuration option,
to force the route segment selection in a proper order.


I'm using SD on Android and on PC (3.8.2.0).
By ckurz7000 - 9/14/2017 1:05:11 PM

I guess the problem is that whatever automatism you program into SD it will work in some situations while causing its own problems in others. In total you haven't gained much except increased complexity of the code. There are workaround solutions (as I suggested in my previous post) for pretty much all situations.So I understand Tim's point of view.

-- Chris.‌‌