-
-
Notifications
You must be signed in to change notification settings - Fork 504
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
Adding support for ArduPilot #728
Comments
I can see different ways to achieve that (and I'm looking for more thoughts). I believe that for each feature, there can be 3 situations:
Because features are grouped into plugins, that applies to plugins as well. The following scenarios could then occur:
The questions I have would therefore be:
Great contributions would be to test the current SDK against an APM SITL and list the features/plugins that are working or not, and possibly why. |
I suggest use the same interface but different implementation what peter had done before. because the different between APM and PX4 is not too much bust just some detail in MAVLINK, therefor we could implement takeoff and land example in APM sitl first. |
Could we start a list of differences we know? I've heard that there are "not so many" differences quite a few times, but I still have no clue what that means and what they are :-). |
@auturgy and @peterbarker probably the best people for this. Generally speaking the systems use the same messages to achieve the same things, and will often use the same "main" message sequence. They may however use different sequences for edge cases, or use things that are not clearly defined in the spec. The ones with highest impact are parameter protocol, mission protocol and command protocol.
In addition, ArduPilot uses different modes - ie Guided vs Offboard and may require different sending rates when in these modes. I expect you'll discover lots more. Let me know - then I can document them :-) |
Just so they’re listed: Peter and Sid (@bugobliterator) have both done relevant work, although quite some time ago. Someone might be able to build on one of them.
https://github.com/peterbarker/DroneCore/tree/ardupilot
https://github.com/bugobliterator/DroneCore/tree/pr-apm-dronecore
Regards,
James
… On 29 Apr 2019, at 12:17 pm, Hamish Willee ***@***.***> wrote:
@auturgy and @peterbarker probably the best people for this. Generally speaking the systems use the same messages to achieve the same things, and will often use the same "main" message sequence. They may however use different sequences for edge cases, or use things that are not clearly defined in the spec.
The ones with highest impact are parameter protocol, mission protocol and command protocol.
Param protocol high level differences here: https://mavlink.io/en/services/parameter.html#implementations
Mission protocol high level differences: https://mavlink.io/en/services/mission.html#implementations
Command protocol differences are not documented yet (so I don't know what they are). The main difference is that I believe ArduPilot does not use the LONG form of commands, so suffers rounding errors for positional messages.
In addition, ArduPilot uses different modes - ie Guided vs Offboard and may require different sending rates when in these modes.
I expect you'll discover lots more. Let me know - then I can document them :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Also, for testing: is there a SITL that can run headless (e.g. on a CI server) for APM? We will need something like that to run integration tests. |
… On 24 May 2019, at 2:52 pm, Jonas Vautherin ***@***.***> wrote:
Also, for testing: is there a SITL that can run headless (e.g. on a CI server) for APM? We will need something like that to run integration tests.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hi, has there been any movement/development on this? |
Unfortunaly, not that I am aware of. On my end, I would still like to have an idea of the differences between PX4 and APM, in order to open a discussion also at the MAVLink level. IMO MAVSDK should implement the "standard" set of messages (presumably APM does implement parts of What do you think @fnoop? Could you help with that? |
@JonasVautherin Just FYI, ArduPilot differs in (at least) Mission and Parameter protocols. Probably also in the command protocol, but I haven't documented that properly, so no detail. EDITED: Deleted, just realised I posted most of this above already: #728 (comment) @fnoop FWIW While it will be much easier to add ArduPilot-specific plugins, long term it will be better for the standard and for ArduPilot maintenance to work on making the protocol implementations of the common protocols "more compliant". |
Hi All, These are my current thoughts / action plan:
|
Initial testing of MAVSDK examples and integration tests result in a segfault occurring in the ardupilot SITL application. Looking into why this might occur... |
[New Thread 0x7ffffab80700 (LWP 8519)] gdb is not being kind to me but it looks like ardupilot is bombing out when the forwarded message is received by ardupilot. I will have to add some debugging on the ardupilot side to see why the heartbeat (msgid = 0) is causing this issue. |
Heartbeat from MAVSDK? |
Yeah, looks that way. If you can think of anything that may be responsible for a segfault in a heartbeat packet... It seems unlikely but certainly the ArduPilot SITL is exiting as soon as that heartbeat is sent. |
It seems that one aspect on which MAVSDK relies and where PX4 and APM differ is the flight modes. Flight modes are not part of the MAVLink specification, and MAVSDK currently uses the PX4 definitions (because it is developed and tested against PX4). However, there has been work towards specifying common flight modes (see e.g. here). The current state, as far as I can tell, is that the PX4 community is open to working on a flight modes specification and updating PX4 to comply with it, but this cannot be done unilaterally. Anybody wanting to work on that part on the ArduPilot side would be more than welcome to the discussion 😊. |
I’m part of the discussion.
ArduPilot already implements modes via mavlink, and has done for many years. This might be a useful reference for you:
https://ardupilot.org/dev/docs/apmcopter-adding-a-new-flight-mode.html
Regards,
James
… On 13 Jun 2020, at 7:37 am, Jonas Vautherin ***@***.***> wrote:
It seems that one aspect on which MAVSDK relies and where PX4 and APM differ is the flight modes. Flight modes are not part of the MAVLink specification, and MAVSDK currently uses the PX4 definitions (because it is developed and tested against PX4). However, there has been work towards specifying common flight modes (see e.g. here).
The current state, as far as I can tell, is that the PX4 community is open to working on a flight modes specification and updating PX4 to comply with it, but this cannot be done unilaterally. Anybody wanting to work on that part on the ArduPilot side would be more than welcome to the discussion 😊.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Hi, How would you prefer to integrate it into the MAVSDK CI tests? Should I provide the docker file like the PX4 sitl at MAVSDK Github Actions PX4-SITL or simply the docker hub tags are sufficient. The github repo to the current development is at: Ardupilot SITL Headless. The project was inspired by another such development from radarku. The main difference is the multi-stage docker build approach to bring the image size from 4GB to 700MB. |
An Ardupilot MAVSDK integration testing suite does not exist at the moment for MAVSDK and would be much appreciated. I have used the radarku SITL image for my personal testing and it has worked well. If you are happy to contribute your docker file that would be useful. Then we can set up some integration tests to work with GitHub actions and the new Ardupilot dockerfile |
Happy to contribute. Need some guidance on next steps though. Should I create a pull request with the addition of docker files for Ardupilot SITL and changes in the github action file to include the Ardu-SITL jobs as well? |
Hi, Is there any progress to this topic? I would like to know the status and how can I contribute. |
Hi @prokas-nikos thanks for writing. So, in general, we want to try to minimize specific hacks and move towards a spec that both flight stacks are compatible with. These discussions and work is generally done in the MAVLink call every two week. One thing that is being standardized is common flight modes, so one goal would be to implement that for ArduPilot, PX4, MAVSDK, etc.. Apart from that, in the meantime, you can always test specific functionality that you need/use with MAVSDK and check whether it works, and if not, fix it ;). |
@JonasVautherin hi, I'm dealing with this at the moment connecting MAVSDK with Ardupilot SITL. So far I've found Ardupilot does not support MAVLINK_MSG_ID_PING which is used in system_impl.cpp line 279. I get intermittent disconnections from the ardupilot side (After disabling disconnections from the MAVSDK side in tcp_connections). I still get Ardupilot resetting the connection, but like I said, sometimes it works, sometimes it doesn't. By the way, I'm only using the command and mavlink passthrough plugins from MAVSDK. |
Hello all, I am noticing some actions about this topic. I can see that in Action Class there is a mapping between Ardupilot Modes and PX4 Modes. I am trying to send mission commands to ArduPilot but I fail. I just want to ask if there is a release notes document where we can track the changes regarding the topic of Ardupilot functionalities in MAVSDK and know if I have to implement something on my own or I am misusing the MAVSDK api. |
@prokas-nikos I would suggest you write a small example showing what you are trying to do, open a new issue with it, and explain what you expect and what happens instead 😊. That will help people understand your problem better, and possibly help you 👍. |
I will tell you that I run Ardupilot SITL missions using MAVSDK |
There is some support for Ardupilot now and we even run some integration tests against Ardupilot in the CI. I'd say we can close this one. PRs are welcome when needed or if contributors want to enable more integration tests in the CI. |
What is the "some support" any doc about this? I tried gotoLocation and mission, both are not working for Ardupilot. But same code are working well on px4. |
@LiangHuangBC I found out that for ardupilot the working lib was missionraw |
@LiangHuangBC A Document describing the support does not exist yet. I did make an excel sheet describing the current implementation status for APM the link to this is here: GoToLocation is not supported yet. For Mission, you should use MissionRaw plugin and please Follow the sequence to start the mission-> Arm(), Takeoff() and then StartMission() as done in the following Integration test: Mission Integration Test for APM Actually, the best way to check support for APM is to simply go through the tests starting with APM (test only meant to run with APM) or NOT starting with PX4 (test meant to work with both PX4 and APM.) Hope that helped :) |
Can you please comment about this specific situation in #1990? Thanks. |
@ykhedar thanks for linking these tests. I ran them in conjunction with ArduPilot SITL which connects (use udp port 14550). Uploading a mission does not however work and I get an error saying that the sequence is invalid, as below:
I did some digging into the Python DroneKit sdk to see what format they use and it looks like they have a different structureas linked. Shown below as well:
Looking at MavSDK's approach, I see that we are missing the first two (Target System and Target Component) and we have an extra parameter at the end (Mission Type). Perhaps this issue has arisen due to ArduPilot developments since your original post? I started modifying the MissionItem struct, building the SDK etc. but it didn't seem as straight forward as I was hoping! Perhaps someone in the dev team can check this one out? Happy to test the code in a branch with ArduPilot SITL too. Thanks in advance! |
Hi @OliverHeilmann, Looking closer at the warning, it is caused by this for loop:
Now lot of ifs: This seems to be added few months before or at least after September 2022 which is the last time I checked the mission raw worked fine for Ardupilot and use the server built at that commit version which continues to work for me. If you are using the newest mavsdk server it should contain this check which basically checks if the index of the mission item list is always one greater than the value of seq in that mission item. It seems reasonable and should not cause problem as long as you are using the exact same code to create the mission plan. So I would ask you to check the following:
My only guess is somehow while marshal/unmarshal of the mission item, the seq value at mission item 1 is dropped since protobuf likes to not send over default values and we are not handling it correctly in the check mentioned above. I might able to have a look at it in a few days or sooner, until then if you can identify the problem would be nice ;) Best, |
Alright so i did have a look and to me the check for ardupilot mission seems not to be correct. ArduPilot Mission Plan sequence starts at 0 just like PX4, its just that the item 0 should be home position and item 1 should be takeoff and then follows other mission commands. @julianoes since you implemented this check way back, just wanted to ask if I am missing something here? If not then I would simply remove the if/else blocks and check if seq is starting at 0 and increments monotonically. |
Ok, so that's not matching what I was told when I first asked about this. And it did sound very odd to me. I'm happy to change it if it's really wrong. It would be nice to get some sort of confirmation or proof though. |
I followed your suggestions @ykhedar and commented out the check you linked, built the project again and then ran the test that you have posted above. Looks like the mission/ flight plan is uploaded correctly with the fix (I added a comment with lots of ! to clearly mark the point). Arm then fails but this is a gyro inconsistency issue which does not seem code related - will investigate further and post anything relevant.
@julianoes thanks for looking into this as well. I see you merged and posted says the below. What does this mean in reference to a fix going forward? Thanks!
EDIT!I just ran a cut down version of the mission integration tests using ArduRover SITL software and the mission elements I did also have to cut out the ASSERT_EQ line for setting takeoff altitude as this test fails consistently with the following error:
|
Hi, @OliverHeilmann, the PR #2064 was the fix to the problem and it was merged, so you should be able to compile the latest master branch and should not see the problem. Regarding the set_takeoff_issue, i guess in rover that command is not supported i guess :D Since rover cannot change takeoff altitude. So its fine to comment that out. |
Also its better to open a new issue if you face further problems, rather than discussing in an old and closed issue ;) |
This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: |
Context
A while ago, @peterbarker worked on adding support for APM in the SDK (here). More recently, @jinchengde (and others) started looking into that, again. The goal of this issue is to discuss the high-level requirements and architecture.
Benefits for APM
The project is architectured in such a way that everything relies on a C++ MAVLink implementation. Making this implementation compatible with APM means that APM will also get the language bindings (Python, Swift, Java and future ones like Javascript).
The interface common to all our bindings is defined here and is used to auto-generate language-specific APIs (e.g. using RxSwift in Swift, RxJava in Java, and asyncio in Python).
SDK architecture (overview)
The SDK can been seen as composed from 4 parts:
At the lowest level, each plugin (defined by one proto file) is a C++ library. The backend uses those libraries, as can been seen here.
The text was updated successfully, but these errors were encountered: