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

Added gimbal plugin #124

Merged
merged 2 commits into from
Oct 26, 2017
Merged

Added gimbal plugin #124

merged 2 commits into from
Oct 26, 2017

Conversation

julianoes
Copy link
Collaborator

This adds a plugin which can set pitch and yaw angle of a gimbal.
Currently, the commands are sent to component ID 1, so the assumption is
that the gimbal is connected to the autopilot and not talking mavlink
itself. This could change or be made adaptable in the future.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 48.37% when pulling 6d77586 on add-gimbal into ce714f5 on develop.

UNKNOWN
};

static const char *result_str(Result result);
Copy link
Collaborator

Choose a reason for hiding this comment

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

No docs on any of this.

static const char *result_str(Result result);

typedef std::function<void(Result)> result_callback_t;

Copy link
Collaborator

Choose a reason for hiding this comment

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

Need to add docs and make clear co-ordinate frame used.

explicit Gimbal(GimbalImpl *impl);
~Gimbal();

enum class Result {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why only this set? Can a camera not return CommandDenied, Busy or whatever?

@hamishwillee
Copy link
Collaborator

Currently, the commands are sent to component ID 1, so the assumption is that the gimbal is connected to the autopilot and not talking mavlink itself. This could change or be made adaptable in the future.

So is component ID = 1 the autopilot? - ie we're assuming that the gimbal is part of the autopilot?

Don't Yuneec use a MAVLink camera? I.e. don't we already have a case of a camera that might have a separate component ID? I'd be tempted to add a mechanism to support that now. If not, then this "limitation" should be part of the documentation.

A few other thoughts:

  • Is it possible for a vehicle to have multiple gimbals?
  • Is it possible that a gimbal will have connection semantics?
  • What else might we want to do other than control pitch and yaw?
    • Any other axis?
    • Power up/down? Retract?
  • What if a camera only allows control over a single axis? Errors reported?

@coveralls
Copy link

Coverage Status

Coverage remained the same at 48.634% when pulling f3a65a3 on add-gimbal into bf80f02 on develop.

@julianoes
Copy link
Collaborator Author

So is component ID = 1 the autopilot? - ie we're assuming that the gimbal is part of the autopilot?

Don't Yuneec use a MAVLink camera? I.e. don't we already have a case of a camera that might have a separate component ID? I'd be tempted to add a mechanism to support that now. If not, then this "limitation" should be part of the documentation.

Both cases are possible. I'm not sure which one makes sense to implement, and an automatic mechanism needs a bit more work. For instance, you can check if you have received heartbeats from a gimbal component ID. If yes, you send the commands there, otherwise to the autopilot.

A few other thoughts:

- Is it possible for a vehicle to have multiple gimbals?

If you have different component IDs for the multiple gimbals, yes. Right now, only one exists MAV_COMP_ID_GIMBAL.

- Is it possible that a gimbal will have connection semantics?

It would be heartbeats being sent from the gimbal component ID, as suggested above.

- What else might we want to do other than control pitch and yaw?
    - Any other axis?

There is roll but I have never seen a drone that wants to have a roll axis different from horizontal 😄

    - Power up/down? Retract?

This is all hypothetical. We can add/implement this when there is an actual use case.

- What if a camera only allows control over a single axis? Errors reported?

No idea. I have to ignore anything that does not have a real use case right now. There are endless possibilities.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 48.634% when pulling 0986070 on add-gimbal into bf80f02 on develop.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 48.634% when pulling 0986070 on add-gimbal into bf80f02 on develop.

@mrpollo
Copy link
Member

mrpollo commented Oct 23, 2017

@julianoes please rebase

This adds a plugin which can set pitch and yaw angle of a gimbal.
Currently, the commands are sent to component ID 1, so the assumption is
that the gimbal is connected to the autopilot and not talking mavlink
itself. This could change or be made adaptable in the future.
@coveralls
Copy link

Coverage Status

Coverage remained the same at 48.634% when pulling 97f5fd7 on add-gimbal into 8df5d52 on develop.

@hamishwillee
Copy link
Collaborator

OK, so re that whole discussion, sure - no point implementing anything that has no real use case.

I still lean towards proper support for MAVLink camera though - on the basis that it sounds like we do have real use cases.

@julianoes
Copy link
Collaborator Author

Support for a mavlink camera? Absolutely! But this is just for a gimbal, and I don't know of a mavlink gimbal yet.

@hamishwillee
Copy link
Collaborator

OK, good point. I'll got back to my corner now.

Happy for this to go out. Just FMI, is it possible to get confirmation that the gimbal has reached its target attitude?

@julianoes
Copy link
Collaborator Author

Happy for this to go out. Just FMI, is it possible to get confirmation that the gimbal has reached its target attitude?

So if a gimbal sends MOUNT_ORIENTATION that's what you can use to track the actual angle.

@hamishwillee
Copy link
Collaborator

Just FMI, is it possible to get confirmation that the gimbal has reached its target attitude?

So if a gimbal sends MOUNT_ORIENTATION that's what you can use to track the actual angle.

Should we expose the current orientation through this API?
I guess you could argue that people know what orientation they want so they can set it and it will change if it is different, or nothing will happen if it is already on that orientation. I lean towards exposing the information, but then you end up with "nothing" if the gimbal isn't sending information. Hmm.

@julianoes
Copy link
Collaborator Author

@hamishwillee yes you're right, we should expose it. I'm just wondering if we should expose it in telemetry or gimbal?

@julianoes
Copy link
Collaborator Author

I think we can add that in telemetry sometime. I'll merge this for now.

@julianoes julianoes merged commit 97d98b9 into develop Oct 26, 2017
@julianoes julianoes deleted the add-gimbal branch October 26, 2017 16:44
@hamishwillee
Copy link
Collaborator

@hamishwillee yes you're right, we should expose it. I'm just wondering if we should expose it in telemetry or gimbal?

I think we can add that in telemetry sometime. I'll merge this for now.

Sounds good. I added #141 to track this. I tend to agree "Telemetry" is the right place for this, but it isn't a strong belief and you could easily convince me otherwise. Either way, if it goes in Telemetry we should add cross link/info in Gimbal docs.

dlech pushed a commit to dlech/MAVSDK that referenced this pull request Jan 14, 2022
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