Skip to content
This repository has been archived by the owner on Aug 3, 2021. It is now read-only.

Problems with Vicon and Hovering #193

Open
EceChaik opened this issue Oct 22, 2020 · 6 comments
Open

Problems with Vicon and Hovering #193

EceChaik opened this issue Oct 22, 2020 · 6 comments

Comments

@EceChaik
Copy link

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
Copy link
Owner

whoenig commented Oct 23, 2020

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

whoenig commented Oct 26, 2020

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
Copy link
Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants