Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mission protocol extension: Start by adding a receive example #5779

Closed
wants to merge 1 commit into from

Conversation

LorenzMeier
Copy link
Member

@DonLakeFlyer This allows to extend the complete mission protocol according to your proposal. You can run this against QGC on your Mac by running:

make posix jmavsim

It should lend itself as a pretty good reference implementation as its self-contained.

@LorenzMeier
Copy link
Member Author

@DonLakeFlyer Any updates on this?

@DonLakeFlyer
Copy link
Contributor

DonLakeFlyer commented Dec 9, 2016 via email

@LorenzMeier
Copy link
Member Author

@DonLakeFlyer Our need for this is getting very quickly much more urgent. Any chance to have a look at this in the next days?

@DonLakeFlyer
Copy link
Contributor

Still closing down 3.1 fixes/changes.

@LorenzMeier
Copy link
Member Author

@DonLakeFlyer This would also benefit from running at higher priority.

@DonLakeFlyer
Copy link
Contributor

I don't get how this code is supposed to work:

		unsigned mission_type = 0;
		bool write_failed = false;

		dm_item_t dm_item;

		switch (mission_type) {

mission_type is always 0. Where is mission_type supposed to come from to get it to write fence or rally points?

@DonLakeFlyer
Copy link
Contributor

Also what am I supposed to write for a rally/fence point? The current FENCE_POINT and RALLY_POINT items are ardupilot dialect only.

@dagar
Copy link
Member

dagar commented Feb 1, 2017

Trying to remember what we discussed here, but I think mission_type would be a field added to the existing mavlink MISSION messages.

@DonLakeFlyer
Copy link
Contributor

If that's the case then it's going to need to be coordinated with ArduPilot folks unless it can be changed in a way that doesn't affect them.

@dagar
Copy link
Member

dagar commented Feb 1, 2017

@LorenzMeier should respond with what he intended, but wouldn't it work if mission_type was an extended field (mavlink v2)? Mavlink v1 would default to the current behaviour only allowing you to sync regular waypoints.

@DonLakeFlyer
Copy link
Contributor

I'm quite confused by the current state of mavlink 2. As far as I know it won't work with the current SiK Radio firmware and it won't work with the current WiFi firmware. Hence I don't see how anyone is actually using Mav 2? So if this is mavlink 2 only, i don't see how anyone gets the feature?

@magicrub
Copy link
Contributor

magicrub commented Feb 1, 2017

This commit here looks like MAVLink2 was added to SiK radios in May 2016
ArduPilot/SiK@3e4f55d

@DonLakeFlyer
Copy link
Contributor

I was having a discussion with tridge on how to implement mav 2 with respect to the capability bit where this radio thing came up. Maybe he was concerned about the fact that most radios wouldn't have updated firmware as opposed to it not being possible.

@LorenzMeier
Copy link
Member Author

Don, this is an example. I think you lost all the context from your own proposal, do. let me bring it back to you:

  • You proposed to add Fence and Rallye into the current mission setup by either including a separator item or by choosing an appropriate MAV_FRAME id (the latter seems better suited)
  • the same can be done for planned home to disambiguate it from a waypoint
  • we would add a MAV_CAPABILITIES flag to indicate support for this

On the MAVLink 2 front: Anything that is not legacy is using it. Or in other words: Anybody actively contributing in APM or PX4 needs it and might even already depend on it.

@DonLakeFlyer
Copy link
Contributor

I get that. But I was kind of expecting some sort of implementation of that. I'm not going to have time to implement the firmware side as well. Also if it's going to be a new thing then we need to discuss across with ArduPilot folks as well for common usage.

Two options:

  1. Move fast: Just implement to ArduPilot spec and move messages to common. Then move to Step 2.
  2. Move slower: Discuss/Design new thing.

@DonLakeFlyer
Copy link
Contributor

It's going to be harder for me to complete a #2 discussion/implementation in the next couple weeks. Since I'm currently sitting in the back of my van in the Florida Keys I have very limited discussion bandwidth. But I still do have decent coding bandwidth.

@dagar
Copy link
Member

dagar commented Feb 2, 2017

@DonLakeFlyer if you wanted to pursue mavlink/mavlink#626 it wouldn't take much more work to make this PR functional. I could help on the firmware side if it would unblock you.

Previous discussions for reference.
mavlink/mavlink#626
mavlink/mavlink#617

@DonLakeFlyer
Copy link
Contributor

@dagar Yeah this would be good. If everyone is ok with it waiting about a week to re-kick this discussion to completion. I can't really respond until I get home and get more bandwidth.

@dagar
Copy link
Member

dagar commented Apr 12, 2017

Superseded by #6888

@dagar dagar closed this Apr 12, 2017
@dagar dagar deleted the mission_extension branch November 26, 2017 20:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants