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

Adding Ardupilot SITL to MAVSDK CI #1669

Merged
merged 8 commits into from
Feb 15, 2022
Merged

Adding Ardupilot SITL to MAVSDK CI #1669

merged 8 commits into from
Feb 15, 2022

Conversation

ykhedar
Copy link
Contributor

@ykhedar ykhedar commented Jan 15, 2022

Following discussion on Issue #728 for adding Ardupilot support in MAVSDK (related issues #1562 and #1568), this pull request adds Ardupilot SITL (Copter, Rover) along with necessary changes needed to run it successfully. Currently onnly 3/34 Integrations tests pass. Some notes about changes made:

  1. Added Dockerfiles each for Copter and Rover Firmware versions 4.1.2
  2. Edited the script for building and pushing the new docker files.
  3. Edited run-sitl-tests.sh, start_px4_sitl.sh and stop_px4_sitl.sh to include ardupilot related sitl codes. May need to change the file names in the future. e.g. start_px4_sitl.sh -> start_sitl.sh.
  4. Added code block for running ardupilot sitl into the github actions file.

Requesting Review and Suggestions,
ykhedar

P.S. Congrats on the v1.0 release of MAVSDK :)

Copy link
Collaborator

@JonasVautherin JonasVautherin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! It requires the APM containers to be pushed on the mavsdk docker registry, right? I see that the CI is failing to pull them at the moment.

tools/run-sitl-tests.sh Outdated Show resolved Hide resolved
@ykhedar
Copy link
Contributor Author

ykhedar commented Jan 15, 2022

Nice! It requires the APM containers to be pushed on the mavsdk docker registry, right? I see that the CI is failing to pull them at the moment.

exactly. I did all the tests on my account with all images pushed to my docker hub repo. After everything was working, i quashed all the commits into one so as to keep the pull request clean.

Copy link
Collaborator

@julianoes julianoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks quite clean, thank you @ykhedar. Do the tests actually succeed?

@@ -25,61 +25,119 @@ if [[ $AUTOSTART_SITL != 1 ]]; then
exit 0
fi

if [[ -n "$PX4_FIRMWARE_DIR" ]]; then
px4_firmware_dir=$PX4_FIRMWARE_DIR
# PX4 specific SITL Run Code
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we should change the name of these scripts.

Copy link
Collaborator

@julianoes julianoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks quite clean, thank you @ykhedar. Do the tests actually succeed?

@julianoes
Copy link
Collaborator

I have built and pushed the docker images.

@ykhedar
Copy link
Contributor Author

ykhedar commented Jan 17, 2022

Looks quite clean, thank you @ykhedar. Do the tests actually succeed?

No. The tests are going on forever on the CI so I stopped the workflow. When I checked the logs, this was due to bad telemetry health condition inside a while loop in one of the tests for VTOL. Here is the link to the code:

action_transition_multicopter_fixedwing

Should we add maybe a break condition in this test instead of letting the while loop run forever? Maybe do the same for all such while loops in all the tests? Just make the test fail if the while condition is not met after 60 seconds or 120 seconds?

@JonasVautherin
Copy link
Collaborator

Maybe do the same for all such while loops in all the tests?

Generally I think it would make sense if the tests did not hang forever 👍.

This said, for the health, is it failing because of a difference with Ardupilot? Can we fix health_all_ok() easily?

@julianoes
Copy link
Collaborator

We should limit the tests to 45mins, like the PX4 SITL ones.

And if you want to go through all of them, feel free, but I think it's quite a bit of work.

Do the tests run through for you locally?

@ykhedar
Copy link
Contributor Author

ykhedar commented Jan 17, 2022

We should limit the tests to 45mins, like the PX4 SITL ones.

And if you want to go through all of them, feel free, but I think it's quite a bit of work.

Do the tests run through for you locally?

How does PX4 SITL implement the limit of 45 minutes? Cant seem to find the setting for this.

On my local machine i saw 3 tests pass (i swear :D) which now seems to be incorrect. My bad :( .

Should I add a simple timer using std::chrono in the while loop to wait for 30 seconds or so before the loop exits with a failed test? Or do you suggest something better?

@JonasVautherin
Copy link
Collaborator

How does PX4 SITL implement the limit of 45 minutes? Cant seem to find the setting for this.

I think @julianoes was referring to this.

@julianoes
Copy link
Collaborator

@ykhedar it would be best to use this function for checks with timeout:

template<typename Rep, typename Period>
bool poll_condition_with_timeout(
std::function<bool()> fun, std::chrono::duration<Rep, Period> duration)
{
// We need millisecond resolution for sleeping.
const std::chrono::milliseconds duration_ms(duration);
unsigned iteration = 0;
while (!fun()) {
std::this_thread::sleep_for(duration_ms / 100);
if (iteration++ >= 100) {
return false;
}
}
return true;
}

julianoes
julianoes previously approved these changes Jan 18, 2022
Copy link
Collaborator

@julianoes julianoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@ykhedar
Copy link
Contributor Author

ykhedar commented Jan 18, 2022

Nice!

Just made some changes to the commits (squashed them into one) and your review was made stale by git. Also fetched upstream and merged the new commits into ykhedar/MAVSDK.

Apparently 2 out of 34 tests are passing.

JonasVautherin
JonasVautherin previously approved these changes Feb 1, 2022
@ykhedar
Copy link
Contributor Author

ykhedar commented Feb 2, 2022

Thanks @JonasVautherin for your review. Do we need to get all the Ardupilot related Integration tests to succeed before merging this pull request?

@JonasVautherin
Copy link
Collaborator

We already use --gtest_filter in the script running the test. What about adding PX4 in the tests that only pass with PX4, and filter them out in the Ardupilot runs? Enabling a test for Ardupilot would then just require us to remove "PX4" from the test name, so they could be incrementally activated. What do you think?

@ykhedar
Copy link
Contributor Author

ykhedar commented Feb 3, 2022

Sounds like a good idea to me. I would do the necessary changes. Something like this:

TEST_F(SitlTest, ActionGoto) -> TEST_F(SitlTest, PX4ActionGoto) ?

@ykhedar
Copy link
Contributor Author

ykhedar commented Feb 3, 2022

Okay, I did the changes but it seems now some checks related to macOS-framework and ios are failing for some reason and i cannot think of why. Any ideas? :)

@JonasVautherin
Copy link
Collaborator

Grmbl I don't get why the ios build sometimes does that 😞

Copy link
Collaborator

@julianoes julianoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for your work @ykhedar!

@julianoes julianoes merged commit 837bfbd into mavlink:main Feb 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants