whoenig / crazyflie_cpp

C++ Library to communicate with Bitcraze Crazyflie
MIT License
21 stars 38 forks source link

Unable to connect to Crazyflie 2.0 with Crazyradio PA #13

Open klebermc opened 4 years ago

klebermc commented 4 years ago

Hello I am trying to use your library to connect my Ubuntu 18.04 machine to my Crazyflie 2.0, using a Crazyradio PA (firmware version 0.53).

My first question would be: is your library ready to work with that setup?

I will try to describe the problem that I am facing, maybe you can help me with some ideas about what is wrong.

I am facing an issue when I try to declare a new Crazyflie object. And what I could understand is that this will create a Crazyflie object, which will create a Crazyradio object. In my main.cpp code I have:

Crazyflie vehicle1 = Crazyflie( (const string&)"radio://0/10/250K");
std::cout << "getProtocolVersion " << vehicle1.getProtocolVersion() << std::endl;
std::cout << "getFirmwareVersion " << vehicle1.getFirmwareVersion() << std::endl;
std::cout << "getDeviceTypeName "  << vehicle1.getDeviceTypeName() << std::endl;

I took the liberty to insert some prints in the code, just to understand what is happening. The output was the following:

Crazyflie.cpp: Constructor parameters = m_devId=0 channel=10 datarate=250 datarateType=K m_address=E7E7E7E7E7
USBDevices.cpp: USB initialized successfuly
Crazyradio.cpp: Start of crazyradio devid=[0] object constructor!
USBDevices.cpp: The id from USB match with the id I passed to the function!
USBDevices.cpp: foundid == devid!
USBDevices.cpp: libusb_open / opened USB device and initialized m_handle!
USBDevices.cpp: libusb_get_device_descriptor / got a descriptor for the device!
USBDevices.cpp: libusb_set_configuration / set an active configuration for the device: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: libusb_claim_interface / claim the interface: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x01] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
Crazyradio.cpp: sendVendorSetup request: [0x02] status: LIBUSB_TRANSFER_NO_DEVICE
USBDevices.cpp: sendVendorSetup request: [0x03] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x20] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x04] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x05] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x06] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x10] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
Crazyradio.cpp: End of crazyradio [0] object constructor!
USBDevices.cpp: sendVendorSetup request: [0x10] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x06] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x01] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
USBDevices.cpp: sendVendorSetup request: [0x03] status: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
Crazyflie.cpp:  enabled safelink 
Crazyflie.cpp: End of Crazyflie constructor
--- 
getProtocolVersion 2
getFirmwareVersion 2016.09
terminate called after throwing an instance of 'std::runtime_error'
  what():  timeout
Aborted (core dumped)

It looks like the command sent in Crazyradio.cpp -> setAddress(uint64_t address),

libusb_control_transfer(
        m_handle,
        LIBUSB_REQUEST_TYPE_VENDOR,
        SET_RADIO_ADDRESS,
        0,
        0,
        a,
        5,
        /*timeout*/ 1000);

was not sucessfull (even with address being equal to 0xE7E7E7E7E7).

Also, the call Crazyflie.cpp -> getDeviceTypeName() times out.

Do you have any idea what might be happening? And also why the only request that fails to be sent to the radio is "SET_RADIO_ADDRESS (0x02)"?

Thank you very much

whoenig commented 4 years ago

This is definitely a supported combination. Two things come to mind: 1) You seem to run a fairly old firmware version. I am not sure when the getDeviceTypeName query was added in the firmware (the CRTP protocol is not in particular version-safe, unfortunately). Can you see if updating your STM and NRF firmwares resolves your problem? 2) Try disabling safelink, here: https://github.com/whoenig/crazyflie_cpp/blob/master/include/crazyflie_cpp/Crazyflie.h#L15, recompile and test again.