dji-sdk / Onboard-SDK-ROS

Official ROS packages for DJI onboard SDK.
443 stars 309 forks source link

Manual override for P/F mode switch Failed and obtain/release control is not working in 3.3.1 #140

Closed snakehaihai closed 6 years ago

snakehaihai commented 7 years ago

Hi I`m using new 3.3 api to control UAV autonomously using external sensor in indoor environment. for 3.2 control and bypass(using either switch P to F, or from obtain/release ctrl) is fine. I can control UAV using Lidar and sent out control signal at P mode. anything wrong just switch to F mode. The only problem is with IMU update frequency is too low that I can not run vision-inertial based navigation with it.

In 3.3 IMU is published at 400 hz which is ideal. When shit happens in P mode, I have to switch to F mode for the emergency manual override. However, the drone does not regain control from RC. May I ask how to solve this issue?

I tried release control by setting 0 to service /dji_sdk/sdk_control_authority, no ack on release API control in dji_sdk terminal. In rqt_service_caller, I set /dji_sdk/sdk_control_authority to both 0 and 1 In dji_sdk terminal only shows STATUS/1 @ getErrorCodeMessage, L590: STATUS/1 @ getCMDIDSetControlMSG, L731: OBTAIN_CONTROL_SUCCESS

release ack never pop up in the dji_sdk terminal . and

I checked in the code there is release ack code.

So I changed OSDK ROS service cpp file for debugging ACK::ErrorCode ack; if (request.control_enable) { ack = vehicle->obtainCtrlAuthority(WAIT_TIMEOUT); ROS_DEBUG("called vehicle->obtainCtrlAuthority"); std::cout<<"called vehicle->obtainCtrlAuthority"<<std::endl; std::cout<<ack.data<<std::endl; } else { ack = vehicle->releaseCtrlAuthority(WAIT_TIMEOUT); ROS_DEBUG("called vehicle->releaseCtrlAuthority"); std::cout<<"called vehicle->releaseCtrlAuthority"<<std::endl; std::cout<<ack.data<<std::endl; }

it seems that obtain return ack always 2. which i suppose its bool true. release return ack is always 1 which I think its bool false. Then I looked into OSDK3.3.1. In the vehicle.cpp, it gets return status from A3 MCU/FCU. So my best guess is there is return status error in either A3 MCU/FCU.

Can you help to confirm this? And it could be better if you can provide me a solution for emergency override just in case of shit happens.

BTW can you set this to a topic instead of service? So that I can bag it easily to verify the problem. Now seems a bit hard to troubleshoot. Have to go through log which is much more tedious

I`m using dji sdk 3.3.1 and lightbridge 2.

Regards Shenghai Yuan

rohitsantdji commented 7 years ago

Please see #139 .

snakehaihai commented 7 years ago

@rohitsantdji

If I recall correctly, B4 flight, I tested on the ground. only in P mode, I can obtain control. In F mode can not. RED error comes out. But in flight, after I`m in API mode and switch back. and we notice that API can have control no matter in P or F mode for some reason. (or we are not sure whether API has control or not at all, since we tried hard to disarm using lightbridge in both P&F mode and it is not working). We tried all option from lightbridge, to USB joystick. We could not disarm the drone and the drone is pitching 80degree.

Shit only happens when you change authority. B4 changing authority, I have software control. I can yaw pich roll from USBjoy through API. After that, we switch control to RC and back. Can't really confirm whether API has control or not as drone fly sideway 80 degrees and not taking command from both API, rqt_service or lightbridge. **

after series of debugging we notice that ack = vehicle->releaseCtrlAuthority(WAIT_TIMEOUT); was called. but ack was never correct. that's why there is no response in dji_sdk driver terminal. Then I goes into the OSDK release control callback function in vehicle.cpp. it seems performs the same. So i conclude its A3 firmware that have issues.

If you toggle flight mode from F or P to any mode, the SDK should lose control In any mode after this, the SDK should be able to obtain control.

Will confirm this and take a picture to show you tmr

Have you tried to control it first using lightbridge RC then a USB joystick using API then light bridge RC then USB joystick using API . Just tries switch between control mode. B4 you try this, try to mount your drone on a rig. high chance it will lost control as we observed this twice. Both case, drone is stopped only by pull the power off

the same control we tested on 3.1 something, obtain and release control have a message on driver terminal and everything function correctly. no sudden pitch 80 degree thing

Can I check with you, this dji_sdk/flight_control_setpoint_generic works like typical RC just that control by serial, right? Is it in stable mode? I tried to control this using Logitech joystick. but hard. With hokuyo, it can have some sort of stable holding(direct transport from older A3 firmware code, not tuned for this new craft yet). not sure its flight mode issue or not. in 3.1/3.2 we were using attitude_control function call with mode 0x08. Can hold position indoor very well with lidar feedback. whats the difference?

rohitsantdji commented 7 years ago

Are you using an A3/N3 on a custom vehicle, or an M600? Please note that as the docs on control authority say, the behavior is different for both cases.

But in flight, after I`m in API mode and switch back. and we notice that API can have control no matter in P or F mode for some reason.

As i mentioned before, this is expected as per the docs. You should monitor the mode switch positions and send release/obtain control commands accordingly - here is a small snippet that works:

    //! Check RC commands for release control
    curRC = vehicle->broadcast->getRC();
    if (curRC.mode == 10000 && (!isRCToggle))
    {
      isRCToggle = true;
      DSTATUS("Releasing control..");
      vehicle->releaseCtrlAuthority(1);
    }
    if (curRC.mode == -10000 && (isRCToggle))
    {
      isRCToggle = false;
      DSTATUS("Obtaining control..");
      vehicle->obtainCtrlAuthority(1);
    }

isRCToggle is a bool that maintains state.

For the other issue regarding dji_sdk/flight_control_setpoint_generic, please open a new issue since it is unrelated to this discussion and will help others if the two are kept separate.

snakehaihai commented 7 years ago

with UAV on ground for testing. With lightbridge controller off-> called service vehicle->obtainCtrlAuthority ack=2 called service vehicle->releaseCtrlAuthority ack=1 mode switch = P-> called service vehicle->obtainCtrlAuthority ack=2 called service vehicle->releaseCtrlAuthority ack=1 mode switch = A-> called service vehicle->obtainCtrlAuthority ack=2 called service vehicle->releaseCtrlAuthority ack=1 mode switch = F-> called service vehicle->obtainCtrlAuthority ack=2 called service vehicle->releaseCtrlAuthority ack=1

Funny thing is, I remember in some cases, the red warning pop up say I can't obtain control in the dji driver. Just could not remember how I did it

snakehaihai commented 7 years ago

ok previous flight was not turn on enable multple flight mode flag. but trickly thing is once i turn the flag on. restart drones follow thing happens

which is strange. for 1st round of P A F switching. software shows no error in obtain control and release control. for subsequent round. all error pops up.



called vehicle->obtainCtrlAuthority
2 F mode
called vehicle->obtainCtrlAuthority
2 F mode
called vehicle->releaseCtrlAuthority
1 F mode
........
called vehicle->obtainCtrlAuthority
2 P mode
........
.......
STATUS/1 @ getErrorCodeMessage, L590: 
STATUS/1 @ getCMDIDSetControlMSG, L724: RC_NEED_MODE_P

STATUS/1 @ getCMDIDSetControlMSG, L731: RC_MODE_ERROR
called vehicle->releaseCtrlAuthority
0  F mode

STATUS/1 @ getErrorCodeMessage, L590: sdkCtrlAuthorityCallback
STATUS/1 @ getCMDIDSetControlMSG, L724: RC_NEED_MODE_P

STATUS/1 @ getCMDIDSetControlMSG, L731: RC_MODE_ERROR
called vehicle->releaseCtrlAuthority
0  F mode

STATUS/1 @ getErrorCodeMessage, L590: sdkCtrlAuthorityCallback
STATUS/1 @ getCMDIDSetControlMSG, L724: RC_NEED_MODE_P

STATUS/1 @ getCMDIDSetControlMSG, L731: RC_MODE_ERROR
called vehicle->releaseCtrlAuthority
0 A mode

STATUS/1 @ getErrorCodeMessage, L590: sdkCtrlAuthorityCallback
STATUS/1 @ getCMDIDSetControlMSG, L724: RC_NEED_MODE_P

STATUS/1 @ getCMDIDSetControlMSG, L731: RC_MODE_ERROR
called vehicle->obtainCtrlAuthority
0 A mode
...
snakehaihai commented 7 years ago

I verified again. upon start, UAV API can control, no matter what state it is. only upon start after i changed multiple control flight. shows data logger error. cant arm it -> solve error. funny one. need restart couple times. case closed. thanks. For those whos watching this, enable multiple flight mode in dji assistant. restart drone couple time start drone in P mode 1st in API mode. then after that switching has no problem in bypass

snakehaihai commented 7 years ago

Hi i was flying and it went out of control. We verified the problem like below. Although F mode does not allow API control. but even in F mode, RC is not working as well. the terms in https://developer.dji.com/onboard-sdk/documentation/guides/component-guide-control-authority.html is false according to our testing.

Enabled: Flight mode switch on the remote controller represents a selection of 3 modes including P, A, S, G and/or M modes. All modes other than P are used to regain control for the remote controller.

This terms works only in simulation, in actual aircraft with A3 and 3.3.1 sdk, it is not working

the problem can be reproduced as follows

  1. arm the drone in P mode and take off. software can obtain and release the control.
  2. while software obtain control, switch RC switch from P to F mode. it appear to be both software and lightbriedge RC dont have any control at all. emergency by pass is not working

when all of the above is happneing, the terminal still shows correct message. when in P mode obtain and release is allowed, in F mode, obtain and release is not allowed.

I tried in DJI assistant simulation. in simulation, everything works fine. If i switch to F, no matter it is in obtain or release API mode, I can always obtain by pass control. In reality, I can't get bypass. This one is a bit hard to record a video since for a period of time, drone is out of any control. but a similar case(with video) can be found at https://github.com/dji-sdk/Onboard-SDK-ROS/issues/142. Which again simulation works, but actual flight fails.

Are you guys sure that simulator drone and actual A3 drone code are the same?

snakehaihai commented 7 years ago

dji error insufficient payload..then uav go to full throttle and pitch back mode, F mode by pass not working, API by pass not working. how to solve this

rohitsantdji commented 7 years ago

Is your multiple flight modes switch enabled in Assistant? If yes, what are your switch configurations?

snakehaihai commented 6 years ago

Yes I have to enable switch in order to achieve bypass right? Mode are P A S. and in simulation everything is ok.

Enabled: Flight mode switch on the remote controller represents a selection of 3 modes including P, A, S, G and/or M modes. All modes other than P are used to regain control for the remote controller. Disabled: All flight mode switch positions on the remote controller represent P mode. The flight mode switch just needs to be changed for the remote controller to regain control. Control is only temporarily regained, and logic in the onboard computer should monitor the remote controller flight mode switch and stop sending commands to the flight controller if the user needs to use the switch to permanently regain control.

what does this mean? if sdk still sending position hold command through SDK API. even im in A or S mode, sdk may still have control?

snakehaihai commented 6 years ago

To summary the errors.
1.Error insufficient hover thrust blah blah blah -> A3 need enough payload for drone not to fucked up. 2.Possible multiple control mode problems -> Now i`m using P A G mode. 3.P mode disables paradox -> From the manual when P is disabled, rc temporarily regained. I was sending command even it is 0 0 0 0 in regular 10hz basis that cause manual bypass not working. I have to put the publish(vel) inside the callback. as for possible traffic jam inside the callback only can be solved by a sending time filter to limit the number of output at each time. So for autonomous control bypass in this 3.3 api, try not to publish control at the regular basis. as it might fucked up the bypass

After solved those problems, I managed to get it fly with pure SDK mode