motors suddenly shut down #110
Comments
What do you mean by "crazyflie_server node was not able to respond"? Is the radio still blinking? Essentially, a shutdown could be a firmware safety feature, if no further control commands arrive. Markers: For VICON this is fine since the rotor speed is much higher than the mocap frequency. Do you actually observe tracking issues? VM: The main issue there is the USB latency. I believe this can be a few (less than 10) milliseconds. |
Hi Whoenig, In addition, is there a way that I can investigate what actually caused this motor shutdown and therefore prevent this? |
The best way for debugging is to use the uSD card deck and log the on-board data at full speed (over the radio you can only get a subset of the information). You can find more information here: https://wiki.bitcraze.io/projects:crazyflie2:expansionboards:microsd#data_logging. |
Hi, |
Hi,
I am using the Optitrack system, and I was able to hover the Crazyflie. However, the motors will suddenly shut down after a certain period of time (e.g. around 10 s, which is inconsistent in each experiment). It was observed after the motor shut down that the controller node continued publishing inputs to the topic cmd_vel but the /crazyflie_sever node was not able to respond to those inputs. By the way, I attached 6.4 mm markers on the Crazyflie, and I noticed that the camera reflections on the makers sometimes can be blocked by the propellers thus resulting in inaccurate pose measurement. Would this be the reason of motor shutdown?
In addition, I am using ROS kinetic on a 16.04 Ubuntu virtual machine. As you mentioned that using virtual machines will add additional latency and might cause issues with the visualization tools, I am just wondering if you have quantified the significance of the additional latency?
The text was updated successfully, but these errors were encountered: