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

Implement ModuleParams inheritance and DEFINE_PARAMETERS in the LandDetector class #12209

Merged
merged 4 commits into from
Jun 26, 2019

Conversation

mcsauder
Copy link
Contributor

@mcsauder mcsauder commented Jun 7, 2019

Describe problem solved by the proposed pull request
This PR modifies the LandDetector class to inherit from ModuleParams and utilize the DEFINE_PARAMETERS() macro.

This PR also renames _armingSub->arming_sub and parameterSub->parameter_sub to match the most prevalent usage in the other classes.

Test data / coverage
Additional test data and flight logs will be added below.

Additional context
This PR advances the work in #9756 and #11874.

Please let me know if you have any feedback for me on this PR. Thanks!

-Mark

@mcsauder mcsauder changed the title Implement the _paramHandle and _params structures, update_topics() and _update_params() methods in the LandDetector class. Implement the _paramHandle and _params structures, update_topics() and _update_params() methods in the LandDetector class. Jun 7, 2019
@dagar
Copy link
Member

dagar commented Jun 7, 2019

Why not go straight to ModuleParams if you're going to change this?
https://github.com/PX4/Firmware/blob/master/src/platforms/px4_module_params.h

@mcsauder
Copy link
Contributor Author

mcsauder commented Jun 7, 2019

Hi @dagar , I'd be happy to do that if that's a good direction. This PR is mostly trying to stay minimal while getting all of the land detector classes using the same design pattern. Would you want to do it in a 2-punt? This PR aligns the classes, I can submit a separate PR to move them all over to ModuleParams next unless you'd prefer me going that direction with this PR.

Thanks for the feedback! Let me know what you'd like to see!

@julianoes
Copy link
Contributor

Works for me, thanks @mcsauder !

_total_flight_time = ((uint64_t)flight_time) << 32;
param_get(_p_total_flight_time_low, (int32_t *)&flight_time);
param_get(_paramHandle.total_flight_time_low, (int32_t *)&flight_time);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this duplicated with _update_params()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @julianoes , thanks for pointing that out. I think I don't actually understand what the _update_params() call at line 161 is doing right now in the current master branch, (not changed in this PR), as it appears to be doing nothing.

I've pushed up a commit to clean that up. Would you mind looking closely at that with me in the current master branch as well as this PR? Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The last commit I pushed up has an issue that shows up in flight testing. I am reverting it back momentarily.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The commit changing to ScheduleNow() caused the issue I saw. I've reverted back to my first commit, that uses ScheduleOnInterval() and flight tested.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I've got things resolved. Changing to ScheduleNow() required rescheduling in the Run() method. I don't know why ScheduleOnInterval() doesn't play well with JMavSim, something we might need to look into.

Most recent commit fixes issue 12190 and is flight tested here: https://review.px4.io/plot_app?log=70bc2060-629d-4b26-8b0f-b5d0bc00e9fb

@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch 3 times, most recently from 4aec1da to 2332553 Compare June 11, 2019 15:35
@mcsauder
Copy link
Contributor Author

Rebased on current master and re-flight tested: https://review.px4.io/plot_app?log=28669eb5-f8ab-494a-b3e1-deab987a4b17

@mcsauder
Copy link
Contributor Author

Why not go straight to ModuleParams if you're going to change this?
https://github.com/PX4/Firmware/blob/master/src/platforms/px4_module_params.h

To do this, what is the correct substitution for param_set_no_notification()?

@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch from 634ea18 to eebf15c Compare June 13, 2019 20:10
@bkueng
Copy link
Member

bkueng commented Jun 14, 2019

To do this, what is the correct substitution for param_set_no_notification()?

https://github.com/PX4/Firmware/blob/master/src/platforms/px4_param.h#L131

@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch from eebf15c to 0521a19 Compare June 14, 2019 14:35
@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch 3 times, most recently from 77d5c4d to 91b6c48 Compare June 18, 2019 18:37
@mcsauder mcsauder changed the title Implement the _paramHandle and _params structures, update_topics() and _update_params() methods in the LandDetector class. Implement ModuleParams inheritance and DEFINE_PARAMETERS in the LandDetector class Jun 18, 2019
@mcsauder
Copy link
Contributor Author

mcsauder commented Jun 18, 2019

Why not go straight to ModuleParams if you're going to change this?
https://github.com/PX4/Firmware/blob/master/src/platforms/px4_module_params.h

@dagar, done.

@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch 2 times, most recently from 130851e to c8a1aff Compare June 18, 2019 19:22
@mcsauder mcsauder changed the title Implement ModuleParams inheritance and DEFINE_PARAMETERS in the LandDetector class [WIP] Implement ModuleParams inheritance and DEFINE_PARAMETERS in the LandDetector class Jun 18, 2019
@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch 2 times, most recently from d1c6f5d to 90d45d9 Compare June 18, 2019 20:09
@mcsauder mcsauder changed the title [WIP] Implement ModuleParams inheritance and DEFINE_PARAMETERS in the LandDetector class Implement ModuleParams inheritance and DEFINE_PARAMETERS in the LandDetector class Jun 18, 2019
@mcsauder
Copy link
Contributor Author

@dagar , @julianoes , and @bkueng ,

I have the merge conflicts cleaned up and the ModuleParams inheritance implemented and pushed up in this PR rebased and tested with today's master.

I validated that the total flight time is being set correctly by force saving the LND_FLIGHT_T_LO param to 4,284,967,295, (ten seconds below the maximum value), and LND_FLIGHT_T_HI to 0. I then armed the vehicle and allowed it to stay armed for more than 10 seconds. The results on the bench and a flight test produce this log with successful auto disarm on landing: https://review.px4.io/plot_app?log=fe84fee0-6f89-4614-aa9d-d7def8e0c50d

image

image

hrt_abstime _takeoff_time{0};

perf_counter_t _cycle_perf;
perf_counter_t _cycle_perf{(perf_alloc(PC_ELAPSED, "land_detector_cycle"))};
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
perf_counter_t _cycle_perf{(perf_alloc(PC_ELAPSED, "land_detector_cycle"))};
perf_counter_t _cycle_perf{perf_alloc(PC_ELAPSED, "land_detector_cycle")};

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed! Thanks for spotting that!


void _check_params(bool force = false);
Copy link
Member

Choose a reason for hiding this comment

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

Why is force removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi Beat, thanks for your review! I removed force because check_params() is private, so we know nothing outside of the class is utilizing it, and the only place it now gets called is setting force to false, so it has become unneeded.

Copy link
Member

Choose a reason for hiding this comment

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

It needs to be called with force=true here: https://github.com/PX4/Firmware/pull/12209/files#diff-1fd2cab203a1ba1c362f2dd76a74542fL84. Otherwise _total_flight_time does not necessarily get initialized. This only worked because there were other param changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi Beat. So this is broken in current master? I have to admit that I'm a little confused, in the tests I show above only the LAND_FLIGHT_T_HI and LAND_FLIGHT_T_LO are changed, no others. It is also verifiable with no parameter chances in the flight logs below. I'll gladly revert this change though if it's important.

Copy link
Member

Choose a reason for hiding this comment

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

So this is broken in current master?

Yes. We always have other param changes at the end of a flight, which is why it worked.

Copy link
Contributor Author

@mcsauder mcsauder Jun 25, 2019

Choose a reason for hiding this comment

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

Hi @bkueng. I pushed up a commit that calls _check_params(true) within the constructor so that it gets initialized once as used to be the case prior to 106ee28.

Let me know if you think this is appropriate, and otherwise, if it needs to be forced at each Run() call, we can deprecate the bool arg and the if statement so that _check_params() can be effectively an _update_params() call each iteration.

EDITED ABOVE - call moved to the constructor.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bkueng , moving to the constructor absolutely breaks the detector. I am removing it and squashing that commit out of existence.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @bkueng, placing the call back in the start() method works fine and I think will satisfy the concerns. Latest commit functions fine, flight tested here: https://review.px4.io/plot_app?log=cdc782c2-9999-4f49-a98a-2de786ce5c6f

Let me know if you have any other thoughts! Thanks again for your review!

src/modules/land_detector/LandDetector.h Outdated Show resolved Hide resolved
@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch 3 times, most recently from eb487df to 8b6788e Compare June 24, 2019 23:35
@mcsauder
Copy link
Contributor Author

@bkueng , re-tested after the latest commit and rebase against PX4:master, land detection is behaving as it does in PX4:master:
https://review.px4.io/plot_app?log=7a907eb7-dcff-42e9-9628-aa534a7ec8c1
https://review.px4.io/plot_app?log=33684687-2d06-4bd8-b7c5-6216187a43ac

mcsauder added 3 commits June 25, 2019 15:42
 - Reduce duplicate code in LandDetector _check_params() method.
 - Standardize naming cases.
 - Implement DEFINE_PARAMETERS() macro.
@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch 2 times, most recently from f4ad0f9 to 77e8671 Compare June 25, 2019 21:48
… out _update_total_flight_time() method in the LandDetector class.
@mcsauder mcsauder force-pushed the vehicle_imu_land_detector branch from 6d8e015 to a0d3f51 Compare June 26, 2019 04:52
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