Inav: Add support for additional mw-nav compatible MSP way point types

[stronnag]

The following MSP / mw-nav compat options are not currently implemented in inav. Please consider them for future releases. Maintaining MSP/mw-nav compatibility where practical is useful as it enables existing ground station software to be used. See https://github.com/iNavFlight/inav/wiki/MSP-Navigation-Messages summary follows:

• ~POSHOLD_TIME (P1 = time in seconds)~
• ~SET_POI (lat, lon): craft always 'head in' to the SET_POI position~
• ~JUMP - P1 = prior WP number, P2 = number of iterations (-1 until mission cancelled)~
• ~SET_HEAD P1=heading (P1 = -1 cancels this mode and SET_POI mode)~
• ~LAND (lat,lon,alt??)~

RTH landing option is covered by #61

2020-04, strike out the 2.5 addtions.

[MichaelCWarren]

Is there any current plan to implement this in the near future?

[digitalentity]

That's a low priority at the moment. What types are you interested in?

[MichaelCWarren]

I'm considering writing a mission planning iOS app and was curious what the future of this feature is. The current waypoint types are fine, but it would be neat if we could implement the others...

Michael

On Dec 16, 2016, at 7:27 PM, Konstantin Sharlaimov <[email protected][e-mail]> wrote:

That's a low priority at the moment. What types are you interested in?

-
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/iNavFlight/inav/issues/154#issuecomment-267728091, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFibRvSJ9Kx-Ka2ZJkcPJ0fNTv_AnO5pks5rIyxjgaJpZM4ID2bI.

[digitalentity]

We will eventually implement more.

[anbello]

These new types of waypoints could be useful for aerial photography & video application, in this way we could use our DIY quads to make things similar to those made with expensive DJI quads (maybe).

[digitalentity]

@anbello yes, we'll eventually implement more waypoint types. This is planned but very low priority task

[anbello]

@digitalentity thanks
SET_POI could be the more interesting

[eziosoft]

@digitalentity I don't get it. In the navigation oriented firmware features that can enhance automatic navigation are "very low priority"

[neagron]

yes it would be great to have all the above features then it will be better than the vector and iNav is for waypoint mission's,please O please

[steviegeek]

I agree please could we have ROI/POI and circle
This would make iNav waypoints so much better :-)
Thanks
Steve

[jimpriest]

Adding my vote to add these features.

[lemarec]

+1 For these features

[eziosoft]

what are the Waypoints types supported currently ?
in navigation.h I found:
typedef enum {
NAV_WP_ACTION_WAYPOINT = 0x01,
NAV_WP_ACTION_RTH = 0x04
} navWaypointActions_e;

so only Waypoint and RTH? What happened to Position Hold?

[jimpriest]

Any reason this has no interest? Seems like an important part of the 'nav' in INav :)

[georgekucher]

I have a VERY BIG interest for this feature. For a looooong time. FollowMe+LookAtMe.
Please...

More over.
Now when we have opFlow+lidarSensor from MATEK))
We can think about altitude estimation for FollowMe mode. In case you are going up or down the hill.

[Jacky2k]

Hi everyone,
I'd like to heat up this discussion again. I am currently trying to implement waypoint hold time function. The problem I came across: For this action p1 is defined as the time and there is no definition for the speed. For normal waypoints speed is also in p1. I'd like to support speed, so the only option without breaking compatibility is using p2 for the speed instead, I guess. Is that the way I/we should go?

Personally if I would redefine that protocol I would put the wait time into p2 of a normal waypoint. There is basically no difference in handling these two types except for waiting after reaching the WP. But I guess that would break compatibility too much? And it would confuse users as they would still have the option to create a timed pos hold wp in mwp and other software.
I am open to suggestions/comments.

[stronnag]

I'd like to heat up this discussion again. I am currently trying to implement waypoint hold time function. The problem I came across: For this action p1 is defined as the time and there is no definition for the speed. For normal waypoints speed is also in p1. I'd like to support speed, so the only option without breaking compatibility is using p2 for the speed instead, I guess. Is that the way I/we should go?

Seems like an expedient solution. Nice to see some movement here.

[Jacky2k]

OK, here we go: https://github.com/Jacky2k/inav/tree/jacky2k_waypoint_hold_feature
This is my piece of software that should enable waypoint hold time. I will not be able to test this in the real world for at least one week. If someone else is willing to risk his/her drone, please go ahead. I tested a bit with fake GPS, but I would be careful.
The time is now encoded in p1, the speed in p2. If you get the latest mwp from the development branch, it will not convert the hold time wps into normal ones.

Edit: It would be great if someone else would have a look at the code as I am quite new to inav and maybe I missed something obvious. For example:

• I don't get what these NAV_FSM_EVENT_STATE_SPECIFIC_3 things are and why you need them.
• I don't know what NAV_PERSISTENT_ID* I am supposed to use. Looks like this needs to be compatible, so I added a new one at the end. Is that ok?
• There were a couple of old defines like MW_NAV_STATE_HOLD_TIMED and I am not sure if those are intendet to be used for waypoint hold time or if that is something old - they are not really used any more.

[stronnag]

If this is going to end up as a pull request (which is the only way it will be merged), it should be developed against development, not master.

[Jacky2k]

Yeah, I was told so. I will try to do both this evening.

[Jacky2k]

I just tried to create a pull request against the current development branch but something went horribly wrong. I just asked for a pull of my branch, not the entire development branch against itself. I don't get it. Can someone who knows git tell me what to do? :D

[stronnag]

You made the mistake that we've all made at one stage; you didn't select development in the final stage of creating the PR. That has now been fixed.

[Jacky2k]

Thanks a lot for that!
Can/should I use the development branch when testing this feature? I guess this branch is generally not considered stable?

[stronnag]

Yes, always use the development branch, it's the most stable :)

[stronnag]

So, masochist that I am, I locally patched @Jacky2k's PH Timed into @giacomo892's JUMP repo. Missions with JUMP and PH_TIME can be uploaded and downloaded via mwp and validate as the same mission. So, assuming this time I actually take the right `plane to the field, Wednesday could be interesting. Actually, I'm sure it will be interesting, just possibly not in the way I expect.

[Jacky2k]

Don't say afterwards that you have not been warned :D

[stronnag]

As #5851 has been flight tested and merged, it's my pleasure to close with issue (at long last).