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

Refactoring of the MAVLink parameter interface #449

Merged
merged 23 commits into from
Jul 26, 2018
Merged

Conversation

julianoes
Copy link
Collaborator

@julianoes julianoes commented Jul 10, 2018

This is a refactoring of the MAVLink paramter interface. Solves #440.

@julianoes julianoes force-pushed the refactor-params branch 2 times, most recently from bf6ea37 to bbd760a Compare July 23, 2018 08:37
@julianoes julianoes changed the title [WIP] Refactoring of the MAVLink parameter interface Refactoring of the MAVLink parameter interface Jul 23, 2018
@julianoes
Copy link
Collaborator Author

Ready for review.

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.

Looks good, but I haven't tested the backend yet. Doesn't this break it?

@julianoes
Copy link
Collaborator Author

@JonasVautherin I don't think it should break it? Which part would be broken?

@julianoes
Copy link
Collaborator Author

@JonasVautherin would be good to get this one in.

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.

Breaking the public API and, therefore, the backend. We'll need to fix that, too.

Copy link
Collaborator Author

@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.

Thx!

static_cast<rpc::action::ActionResult::Result>(action_result));
// rpc_action_result->set_result_str(action_result_str(action_result));
response->set_allocated_action_result(rpc_action_result);
if (response != nullptr) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ah!


actionService.SetMaximumSpeed(nullptr, nullptr, nullptr);
actionService.SetMaximumSpeed(nullptr, nullptr, &response);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Aaaah!

actionService.SetMaximumSpeed(nullptr, nullptr, &response);
}

TEST_F(ActionServiceImplTest, setMaxSpeedDoesNotCrashWithNullResponse)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nice!

We don't need to store params anymore, they are always auto-saved.
This adds a cache for the params so that when you want to get a
parameter, it takes it from the cache if you have received it before.

This will only really be beneficial once plugins can require params
right when they are instantiated respectively when a vehicle is
connected.
We should not assume that the firmware is already set to the default
takeoff altitude because it might have been changed in the past.
We can't always be sure if settings via commands work, so we do need to
supply a way to check for errors.
Also get rid of some unnecessary comments and move the param get
methods so they are together.
Instead of setting a default takeoff altitude just rely on the fact that
the drone itself has a takeoff altitude set by a parameter. This should
avoid surprises where taking off with the SDK has a different altitude
than with other ground stations.
These are not needed anymore because the param system should cache it
for us.
julianoes and others added 10 commits July 26, 2018 15:15
This way we can get rid of some future/promise duplication.
Since we now have an API to set params sync instead of async we can
simplify the way the configuration is applied.

Additionally, it does not really make sense to change the PX4 default
without asking every time the plugin connects. We should rather fetch
the params in the beginning and have them cached for when we need to
change them.
@julianoes julianoes merged commit 3bba68f into develop Jul 26, 2018
@julianoes julianoes deleted the refactor-params branch July 26, 2018 15:14
rt-2pm2 pushed a commit to rt-2pm2/DronecodeSDK that referenced this pull request Nov 27, 2018
Refactoring of the MAVLink parameter interface
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.

None yet

2 participants