-
Notifications
You must be signed in to change notification settings - Fork 17k
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
Build ArduPilot against all.xml rather than ardupilotmega.xml #19929
Conversation
@olliw42 you might like to check the implications for @hamishwillee for visibility |
Thanks @peterbarker ! Doesn't this mean that ArduPilot is now carrying a lot of cruft? I kind of assumed you would build against all.xml for the GCS's but not the autopilot. Is this so you can get development.xml without having to think too much about it? |
many thx for the ping, much appreciated !! as much as I can see, storm32.xml is out-commented in the current ardupilot mavlink repo, so nfc. In the upstream mavlink repo the external dialects are moved to the main xml folder, and included in all.xml. If ardupilot would do the same and build on all.xml, this would be a revolution! A very welcome revolution !! storm32.xml includes ardupilotmega.xml, and I'm not sure how pymavlink handles "recursive" includes, but I assume this has been tested by some of you guys at some points, that pymavlink can handle such include trees. If not, and you would decide to continue to exclude storm32.xml from all.xml, it would be not so much of an issue for me, since those who want to be serious with storm32 and mavlink appear to use BetaPilot anyhow. so, please go along ! :):):) thx for this |
Argh. I think we're going to have to revert this one for a while; ChibiOS is leaving a variable "arming_status" in the global namespace and that's causing us compilation issues as the ASLUAV dialect happens to contain a parameter with the name "arming_status". Srsly. |
Not in our master branch, just in the mavlink commit referenced from our main repo. Sadly, moving forward also happens to kill compilation against asluav... see other comment in here. |
We're going to temporarily remove AVSUAS.xml in our copy of all.xml - hopefully returning it when we sort out the namespace conflict. |
On Mon, 7 Feb 2022, Hamish Willee wrote:
Thanks @peterbarker ! Doesn't this mean that ArduPilot is now carrying a lot of cruft? I kind of assumed you would build against all.xml for the GCS's but not the autopilot. Is this so you can get development.xml without having to think too much about it?
It was actually surpringly few bytes - couple of hundred. It did make me
go and have a look at messages we could potentially delete, mind you :-)
This allows us to *route* packets we don't understand - since we're not
passing stuff on we don't understand, that will be useful.
I think the storm32.xml stuff is most affected by this....
I have run MAVProxy+pymavlink against all.xml without issue.
|
Thanks. FWIW I think the inability to route messages that are not understood is something that should be looked at in the library itself. If not now, then "MAVLink 3". |
mavlink 2.1 would be sufficient: mavlink/mavlink#1347 |
This has the advantage that we will understand and forward packets that we don't understand but are contained in all.xml.
This has the drawback that those checksums aren't free - there is a cost to being able to undersand (and thus route) mavlink messages.