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

offboard: How to specify type of setpoint #588

Merged
merged 5 commits into from
Apr 14, 2020
Merged

Conversation

hamishwillee
Copy link
Collaborator

Hi @Jaeyoung-Lim

Decided to document PX4/PX4-Autopilot#13199 here because who knows when/if mavlink/mavlink#1250 might go in.

Please check

@hamishwillee
Copy link
Collaborator Author

Also, does this affect other vehicle types?

@Jaeyoung-Lim
Copy link
Member

@hamishwillee Awesome thanks!

Yes, in case of the rover, loiter type setpoint will make the rover to stop when the rover is close enough to the setpoint. Other setpoints will make no difference for the normal behavior


* Specify the *type* of the setpoint in `type_mask` (not part of the MAVLink standard).
The values are:
- Following bits not set: vehicle will fly in a flower-like pattern.
Copy link
Member

Choose a reason for hiding this comment

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

For fixed wing, the type masks are set from https://mavlink.io/en/messages/common.html#POSITION_TARGET_TYPEMASK. Unless POSITION_TARGET_TYPEMASK_X_IGNORE, POSITION_TARGET_TYPEMASK_Y_IGNORE, POSITION_TARGET_TYPEMASK_Z_IGNORE are set. This will make the position setpoints to be ignored.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Jaeyoung-Lim I am not certain what point you are making here. Is it it:

  • That the pattern flown is not a flower-like pattern - ie it follows the input setpoings
  • That all of these types are ignored if you're not a position setpoint
  • Something else?

Just trying to understand what is wrong with what is written.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Jaeyoung-Lim Can you clarify. I'd like to push this in to docs early this week.

The values are:
- Following bits not set: vehicle will fly in a flower-like pattern.
- 4096: Takeoff setpoint.
- 8192: Land setpoint.
Copy link
Member

Choose a reason for hiding this comment

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

Take off / Land type setpoints are largely untested. I will have a look if this is still valid.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks, waiting on you for that then! I really need to understand why all of these are actually useful to know - ie what does/can code do differently if it knows a setpoint is being used to land a vehicle?

The reason I need this is that it will inform if the information is generically useful or just useful for PX4.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Jaeyoung-Lim Did you find out answer to this?

* Specify the *type* of the setpoint in `type_mask` (not part of the MAVLink standard).
The values are:
- Following bits not set then normal behaviour.
- 12288: Loiter setpoint (vehicle stops when close enough to setpoint).
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Jaeyoung-Lim What is "close enough"? Is there an acceptance radius defined somewhere?

Also see line above - what is "normal behaviour" - just tracking setpoint until actually on it according to GPS

Copy link
Member

Choose a reason for hiding this comment

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

Yes, it will stop at the waypoint when it reaches the acceptance radius. Normal behavior would be that the setpoint is passed as a reference for the L1 controller

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

  1. Acceptance radius is NAV_ACC_RAD?
  2. I have no idea what this means:

Normal behavior would be that the setpoint is passed as a reference for the L1 controller

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Jaeyoung-Lim Can you confirm/answer?

Copy link
Member

Choose a reason for hiding this comment

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

@hamishwillee Sorry for the late response hamish, the problem is that I would actually need to test all these setpoint types since I am not sure what they are doing

@hamishwillee
Copy link
Collaborator Author

@Jaeyoung-Lim Can we move this along? Appears to have stalled!

@hamishwillee
Copy link
Collaborator Author

@Jaeyoung-Lim

Thanks. Obviously I'd prefer to be exhaustive, but I guess you're saying "not value for effort" to test all these cases, and I'd probably agree.

I will merge this, but can you confirm whether the type of setpoint is relevant to only position setpoints (?) or can/should a velocity setpoint also have a type (e.g. land setpoint)? To fix the merge setpoint I need to know :-)

@Jaeyoung-Lim
Copy link
Member

@hamishwillee I think the setpoint types spread broader through groundstation interface .etc, and I think I lack the understanding on how this is used through out the system. (So using your words, it would be a lot of investment for me)

I do want to understand better how this is used in the firmware, since I am repeatedly running into the problem. (PX4/PX4-Autopilot#14643)

This is for position setpoints.

@hamishwillee
Copy link
Collaborator Author

Thanks. I'll merge for now. It's useful information and we can always extend later.

@hamishwillee hamishwillee merged commit ee0c58e into master Apr 14, 2020
@Jaeyoung-Lim Jaeyoung-Lim deleted the hamishwillee-patch-1 branch April 14, 2020 06:10
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.

2 participants