PX4 Hidden Flight BitMasks

1

This is a request for the PX4 Dev Team to chime in on the purpose and functionality of these hidden flight setpoint typemasks featured below

	bool is_takeoff_sp = (bool)(set_position_target_local_ned.type_mask & 0x1000);
	bool is_land_sp = (bool)(set_position_target_local_ned.type_mask & 0x2000);
	bool is_loiter_sp = (bool)(set_position_target_local_ned.type_mask & 0x3000);
	bool is_idle_sp = (bool)(set_position_target_local_ned.type_mask & 0x4000);

I have been experimenting with outdoor autonomous flight with “success”

What I would like is for somebody to explain what each of these type_masks is used for and how it should be used by a companion computer.

#Land Setpoint#
Based on observation today, the land setpoint typemask is incredible, it simply lands the vehicle at the x,y position specified but ignores the z position request.

#Takeoff setpoint?#
Based on observation the takeoff setpoint also seems to ignore any z-position request.

So would it be best to monitor the position, then change the setpoint bitmask once the desired altitude has been achieved?

#Loiter Setpoint?#
Based on observation this renders the UAV immobile. regardless of the position requested the UAV simply loiters.

So would it be best to apply this setpoint when loitering is desired and movements are undesirable?

#Idle Setpoint?#
Based on observation this setpoint is best if used directly after arming the vehicle to keep the props from spinning uncontrollably?

Is this assumption (will cause the props to spin at default rate), valid?

1 Like
2

Sorry for the late reply. You pretty much got it :slight_smile: . As you realized takeoff/land will ignore Z, and yes you will need to use those setpoints at the right “time” and do the rest yourself. They are there so you can make use of the landing/takeoff logic implemented (and future improvements) in PX4 without having to re-implement that offboard. Loiter, ahm, I never actually used that but yes it should just stay at the setpoint then ;). Idle: precisely

3

Addition to Idle: best used from the point of initiating the offboard connection (so before arming), that will be relevant as soon as you start flying offboard without other control inputs.

4

Just wanted to say thanks Andreas for following up with me. I have had great success using my companion computer, with these newly discovered setpoint bitmasks.

best,

Patrick

1 Like
5

@AndreasAntener @patrick_smith Would you be ready to contribute a page here: https://www.gitbook.com/book/lorenzmeier/mavlink-devguide/details

Or here: https://www.gitbook.com/book/px4/devguide/details

?

6

not sure this is the place to ask but - any reason MAVROS doesn’t seem to support this in it’s SETPOINT_POSITION plugin?

7

@edigotlieb see the setpoint_raw plugin

8

Thanks @AndreasAntener didn’t realize that was the use case. What are the loopback topics for?

9

AFAIK the author just used them for testing

10

A small addon here regarding those bitmask.
After searching why my drone wouldn’t takeoff with the 0x1000 bitmask only in some cases, I have found out it required horizontal speed.

The following bitmask does not work and drone won’t take off:
#define MAVLINK_SETPOINT_TAKEOFF_SP_KO (0x1000 | 0b110111011011) /* Take z pos and z velocity into account */
Here I ask to takeoff (0x1000) and to only consider Z setpoint AND Z speed)

The only way I have found to make it work is to use the following Takeoff SP
#define MAVLINK_SETPOINT_TAKEOFF_SP_OK (0x1000 | 0b110111000011) /* Take z pos and all velocity into account */
It tells to use vx and vy which are both set to 0 in my message and this way it works like a charm.

11

Hi Patrick,

Under your test-case scenario, do you stil need to keep sending SET_POSITION_TARGET_LOCAL_NED during takeoff/land phases? And, do you also need to send command long with MAV_CMD_NAV_GUIDED_ENABLE to enable OFFBOARD?