search

whoenig / crazyflie_ros

ROS Driver for Bitcraze Crazyflie
MIT License
192 stars 205 forks source link

Problems with Vicon and Hovering #193

Open EceChaik opened 4 years ago

EceChaik commented 4 years ago

Hi Wolfgang,

today I added some 6.4mm markers on a crazyflie and incorporated it in Vicon. We are not using vicon_bridge but vrpn_client_ros instead, but I have been able to write something similar to "publish_external_pose_vicon.py" and after logging the crazyflie pose it looks like the onboard estimator is getting the vicon pose properly. However, when I then try to have the crazyflie hover, it always just flies off and crashes. It is baffling because I am doing pretty simple stuff. I simply tried adapting the "Position.py" script, so that it takes off and hovers at the starting position, but as I said it just crashes. Also I tried using the "Hover.py" script but this simply does nothing. Is it possible that Hover() messages are not serviced by the crazyflie when "external_pose" messages are being sent or when the Kalman estimator is used? I can include the code I've used, if you think it will be helpful. Thank you very much

whoenig commented 4 years ago

For the crash, did you verify that the coordinate system matches the ROS coordinate system, especially the orientation?

Hover.py uses a rate-based setpoint, which might not be implemented in all controllers. Are you using the Mellinger or PID controller? (I think PID should work, but Mellinger might not). There should be no limitation with respect to external_pose messages or Kalman estimator.

EceChaik commented 4 years ago

Hmm you mean make sure the vicon data are aligned with the Body frame as seen in " https://www.bitcraze.io/2020/01/state-estimation-to-be-or-not-to-be/ "? I will have to check that for sure

Isn't the PID the default controller? In the code I'm running I'm specifying the Kalman estimator should be used, but I'm not specifying the controller so I would assume it is using the PID. But I'll check that too

EceChaik commented 4 years ago

Yes, that was the issue, I hadn't aligned the object's orientation in Vicon with the Crazyflie's IMU. However, now that I've got it all to work, I'm conflicted about something. For the purposes of a specific experiment, I want to look into commanding specific motor thrusts to the motors. I know this can be done using the bitcraze python libs and perhaps tweaking the firmware a bit, but is there a way to do this using your crazyflie_ros package? Otherwise I will probably have to switch to using the crazyflie-python-libs entirely, cause I don't think I could be using the libs for control, while also communicating with the crazyflie using crazyflie-ros, am I correct?

EceChaik commented 4 years ago

Oh and another thing. Would you say that sending "cmd_vel" messages using this package (i.e. crazyflie_ros) corresponds to the same thing as sending RPYThrust setpoints using the cf_commander of the crazyflie-python libs?

whoenig commented 4 years ago

You cannot use both crazyflie_ros and crazyflie-python-libs simultaneously. I am not aware of any functionality in the official firmware/python-lib that lets you control the motor PWM directly (other than using parameters, but those cannot be changed in realtime). If that's possible there, it would be easy to add in crazyflie_ros also. Finally cmd_vel is the same as sending rpy-thrust setpoints.

EceChaik commented 4 years ago

Thanks, I know there is no method for PWM, but I should be able to add a port and type in the firmware to take advantage of the motorSetRatio firmware methods. Anyway, thanks for the response regarding cmd_vel as well, this might be all I need in the end