Unable to solve this error when i give this command $ rosrun crazyflie_tools scan
it shows
Found Crazyradio with version 0.53
radio://0/100/1M
LIBUSB_ERROR_BUSY
please help me to fix this problem
LIBUSB_ERROR
Re: LIBUSB_ERROR
Does anything else, like the client, uses the radio at the same time? This error looks like the radio is already open by another software. Only one software can open the radio at a time.
Re: LIBUSB_ERROR
no sir, we disconnect it from python client while using ros yet its showing the same error.
Re: LIBUSB_ERROR
I'm currently facing this issue as well. Even after running
The connection did close, but it does not seem to be a full closure since Ubuntu still seems to want to hold on to the CrazyRadio even if there are no active connections.
Strangely, using the crazyflie-ros package instead didn't give this issue, an example is the chooser.py written in Python
https://github.com/USC-ACTLab/crazyswar ... chooser.py, which utilises Python scripts that uses the crazyflie-ros package: https://github.com/USC-ACTLab/crazyswar ... er/scripts
The issue appears when I use the python way of opening a link with the crazyflies aka
And then trying to access a Python chooser.py command (such as battery) after the initial connection has closed using the .close_link() method
But if I were to access a ros command first, then try establishing a crazyflie connection using the .open_link() way, it works fine.
EDIT:
So I continued to experiment, and it seems like the reason for this is not because of the CrazyRadio not giving up the connection. The issue seems to be more on the crazyflie side where it feels as if the crazyflie is 'saving' this connection for a faster re-connection (perhaps a cache?). This is deduced because I replugged the CrazyRadio and nothing changes. But when I restarted the CrazyFlie manually, it suddenly works again.
I'll open a new topic for my issue in the Crazyflie section. Doesn't seem as if it is the same as the issue you are facing now
Code: Select all
self.cf.close_link()
Strangely, using the crazyflie-ros package instead didn't give this issue, an example is the chooser.py written in Python
https://github.com/USC-ACTLab/crazyswar ... chooser.py, which utilises Python scripts that uses the crazyflie-ros package: https://github.com/USC-ACTLab/crazyswar ... er/scripts
The issue appears when I use the python way of opening a link with the crazyflies aka
Code: Select all
self.cf.open_link()
But if I were to access a ros command first, then try establishing a crazyflie connection using the .open_link() way, it works fine.
EDIT:
So I continued to experiment, and it seems like the reason for this is not because of the CrazyRadio not giving up the connection. The issue seems to be more on the crazyflie side where it feels as if the crazyflie is 'saving' this connection for a faster re-connection (perhaps a cache?). This is deduced because I replugged the CrazyRadio and nothing changes. But when I restarted the CrazyFlie manually, it suddenly works again.
I'll open a new topic for my issue in the Crazyflie section. Doesn't seem as if it is the same as the issue you are facing now