Unexpected behavior in offboard mode

[TarekTaha]

I am trying to perform offboard navigation using mavros following this procedure :

• run mavros with vision estimation enabled
• stream pose data to the new /mavros/vision_pose/pose topic (PX4 blinks green)
• arm the quad and fly manually
• switch to posctrl (all fine so far and quad holds position)
• switch to offboard mode (it gets rejected)
  • run the script to send setpoint : offboard mode accepted
  • immediately the quad flips over and motors disengages

script used to send setpoint: https://raw.githubusercontent.com/kuri-kustar/indoor_uav_control/master/scripts/setpoint_demo_2.py

The plot shows how immediately after changing to offboard mode, the motors disengage/go back to trim values.

a similar procedure using the uar_interface works fine: https://github.com/kuri-kustar/c_uart_interface_example/tree/object

[mhkabir]

@thomasgubler

[thomasgubler]

a similar procedure using the uar_interface works fine: https://github.com/kuri-kustar/c_uart_interface_example/tree/object

what is the difference to the python script from the viewpoint of the autopilot --> Do both approaches use the exact same set of mavlink messages?

[TarekTaha]

Well, I tried to trace how the setpoint_position plugin works:

it seems that all it does is subscribe to the topic /mavros/setpoint_position/local , perform some bit bashing (I think it's enabling only position control and disabling velocity and acceleration) and send the data through mavlink https://github.com/mavlink/mavros/blob/d1902d1331d32d30af911f04dcc842a657b209ff/mavros/src/plugins/setpoint_position.cpp#L92-101

On the other hand, the c_uart_interface_example does the following:

• it enables the offboard via mavlink : https://github.com/kuri-kustar/c_uart_interface_example/blob/object/mavlink_control.cpp#L140 , https://github.com/kuri-kustar/c_uart_interface_example/blob/object/autopilot_interface.cpp#L399 , https://github.com/kuri-kustar/c_uart_interface_example/blob/object/autopilot_interface.cpp#L468 (not sure this is needed as I use a switch in the remote RC to enable offboard)
• Set the position setpoint : https://github.com/kuri-kustar/c_uart_interface_example/blob/object/autopilot_interface.cpp#L35 , https://github.com/kuri-kustar/c_uart_interface_example/blob/object/autopilot_interface.cpp#L179
• Send the position setpoint using mavlink : https://github.com/kuri-kustar/c_uart_interface_example/blob/object/autopilot_interface.cpp#L354 and https://github.com/kuri-kustar/c_uart_interface_example/blob/object/autopilot_interface.cpp#L735

So basically on the low level, the fundamental difference is the usage of mavlink_msg_set_position_target_local_ned_pack_chan in

mavros/mavros/include/mavros/setpoint_mixin.h

Line 42 in c26ef5b

mavlink_msg_set_position_target_local_ned_pack_chan(UAS_PACK_CHAN(_uas), &msg,

vs the usage of mavlink_msg_set_position_target_local_ned_encode as in https://github.com/kuri-kustar/c_uart_interface_example/blob/object/autopilot_interface.cpp#L374

That's as far as I could trace it. Now whether this difference is the cause of the problem, and how to fix it is what I need to know with your help.

[vooon]

Different encoders — bug can't be here!
I think more likely this comment api#L47:

    // this is needed for now to avoid a throttle cut...
    sp.vx  = 0.0;
    sp.vy  = 0.0;
    sp.vz  = 0.0;

So you may try edit type_mask:

uint16_t ignore_all_except_xyzy = (1 << 11) | (7 << 6); // ignore velocity vector: | (7 << 3);

[TarekTaha]

@vooon Yes, changing the mask works ! Maybe you should make this change permanent in mavros (Not sure if this would effect APM) ?

I will test the velocity set point next (the velocity setpoint in the current firmware doesn't work, so I will use an older PX4 firmware)

[thomasgubler]

@vooon Yes, changing the mask works ! Maybe you should make this change permanent in mavros (Not sure if this would effect APM) ?

We should fix this in PX4

[thomasgubler]

ah I was to fast...
@BlackCoder did you just change the mask to make it work or is

    sp.vx  = 0.0;
    sp.vy  = 0.0;
    sp.vz  = 0.0;

needed as well?

Probably you were sending 0 for the velocities anyway? I am confused why setting them again to 0 as per @voon 's comment should change something

[vooon]

In mavros velocity vector is zero (all ignored data is zero), but before it ignored.
That comment more related to type_mask, what im changed in 1455fcb .

[vooon]

And i think that it is bug, so this qirk may be removed after fixing PX4/PX4-Autopilot#2036 .

[aerialhedgehog]

api#L47 is definitely a hack. At the time I wrote this, ignoring the velocity components didn't help.

Are you all able to command velocity setpoints? See PX4/Firmware/#1856

[TarekTaha]

@thomasgubler as @vooon said, the mavros sets the velocity vector to zero before sending it, so I just changed the mask
@aerialhedgehog the velocity setpoint in the new firmware is still broken, I am using an older firmware at the moment to test velocity setpoint

[thomasgubler]

@BlackCoder could you lend a hand for debugging the velocity issue?

[TarekTaha]

@thomasgubler yes of course, just let me how do you want to approach it.

[LorenzMeier]

@BlackCoder @aerialhedgehog Have you seen this branch / PR? PX4/PX4-Autopilot#1983

[TarekTaha]

@LorenzMeier , no I didn't see it before. I can test it in the next couple of days. What is the expected behaviour resulting from this PR?

[aerialhedgehog]

@LorenzMeier this is new to me too, will check it out

[vooon]

@LorenzMeier it is fixed?

[supermice]

@LorenzMeier Can I use the velocity control command with master firmware now?

[LorenzMeier]

This is fixed in that it won't cut throttle.