Address configure error

[ryanwallis]

Hi everyone,

Currently, I am attempting to fly around 6 crazyflies (v1s and v2s). It has been suggested that setting individual addresses can be utilized in order to fly 2 crazyflie_v2s with 1 crazyradio and also to avoid interference to individual quadrotors. However, when setting addresses the following occurs:

Either the 'configure' tab of cfclient shows that the address has been written (as in, shows the unique address when connected->configure 2), but I can only connect to it (in cfclient) using the default address 0xE7E7E7E7E7, and using Whoenig's crazyflie_ros package, crazyflie_tools scan, it shows only the channel and bit rate. I.e. radio://0/60/1M, whilst missing the unique address at the end.

The next thing that occurs, is that the address sets correctly, e.g. cfclient shows: radio://0/20/1M/E7E7E7E701, but crazyflie_tools scan can not see that particular connection (returns nothing).

Previous set-ups that had this address-setting sort of working (though nothing is particularly different), had the crazyradio's red led on solid and LIBUSB_TIMEOUT occuring.

Does anyone have any suggestions of what I could be doing wrong set-up wise or what to look at / look out for? I would greatly appreciate it.

Firmware versions:
crazyradio: 0.53
crazyflie v2: cf2-2016.02

Using:
Whoenig's crazyflie_ros
Whoenig's multi_branch cfclient, and the most recent master cfclient (tried both)

Thanks guys

-Ryan

[arnaud]

Hi Ryan,

Can you maybe try the latest version of the Crazyflie firmware (ie. from master). A lot of work has been done stabilizing the memory system for configuration. There is a slight chance the configuration is not well written. Also did you update bot stm32 and nrf51 when updating the Crazyflies? if you updated with the .zip using the client then both have been updated.

I have been using different addresses for the Maker Faire demo and it worked well. In ros I used an address like: radio://0/17/2M/E7E7E7E7BC.

Best,
Arnaud

[ryanwallis]

Hi Arnaud,

I attempted the new firmware stm and nrf (the .zip file 2016.09) - the setting of the addresses within cfclient now appear stable! Thank you

However.... I am still having problems with using addresses with the ROS package by Whoenig, but only when setting these unique addresses... If I use an address of E7E7E7E7E7, and different channels, different radios, it works as expected.

Using: rosrun crazyflie_tools scan, still returns nothing when a unique address is sent
Using: roslaunch multi_hover, the radio and crazyflie appear paired (I can't reconnect to the crazyflie in cfclient when connected during this process, for example), yet there is no data being sent (no green LED, only rapid Red LED on the crazyradio)

Any ideas?

[arnaud]

Can you scan the Crazyflie when setting a unique address by setting the same in the python GUI client?

[ryanwallis]

Hi Arnaud, I am not entirely sure what you mean by the wording, but the configuring and scanning functionality in the python cfclient works fine.

[arnaud]

OK, this is what I meant. So changing the address works in the copter.

I have never used the crazyflie_tool but when I set an address in a copter I simply connect it by providing the address in the copter uri and it has always worked. So if cfclient shows radio://0/20/1M/E7E7E7E701, running something like:

Code: Select all

roslaunch bitcraze_lps_estimator dwm_loc_ekf_hover.launch uri:=radio://0/20/1M/E7E7E7E701 x:=3 y:=2.3 z:=1.0

should work.

[whoenig]

The crazyflie_tools scan utility cannot scan for all possible addresses. Similar to the cfclient, you have to specify the address. The scan utility will then try different channels and data rates to find the Crazyflie. You can run

Code: Select all

rosrun crazyflie_tools scan --help

to find out more about the possible parameters (the same goes for all tools which are part of the package).
The reason why it is not possible to find the address as well is because the search space is too high - there are 2^40 possible addresses.

[ryanwallis]

Hi Whoenig and Arnaud,

The crazyflie_tools scan --address 0xE7E7E7E701 works as expected

I will continue to have a look at what could be going on with the time-outs.

This is what I'm getting currently (No issue when default address used):

[ INFO] [1476693351.202428358]: Connecting to VRPN server at 130.194.136.136:3883
check_vrpn_cookie(): VRPN Note: minor version number doesn't match: (prefer 'vrpn: ver. 07.33', got 'vrpn: ver. 07.20 0'). This is not normally a problem.
[ INFO] [1476693351.211092938]: Connection established
process[rviz-10]: started with pid [9394]
Receive LIBUSB_ERROR_TIMEOUT
[ INFO] [1476693352.214825186]: Found new sender: crazyflie
[ INFO] [1476693352.215071935]: Creating new tracker crazyflie
[INFO] [WallTime: 1476693352.663658] found land service
[INFO] [WallTime: 1476693352.663920] waiting for takeoff service
[INFO] [WallTime: 1476693352.665539] found takeoff service
Receive LIBUSB_ERROR_TIMEOUT

Also occurs with the lps-ros package, though I do not have experience with this package.

[arnaud]

I do not think these timeout are the cause of the problem, they are not related to the radio configuration. You said earlier that the Crazyradio LED was only red, this looks like to be the problem: somehow the radio is not tuned to the right channel/datarate/address. Could you maybe copy-paste the exact roslaunch command line using one of the launchfile present in git so that I could try doing the same here?

/Arnaud

[ryanwallis]

Thank you for your help, I really appreciate it.

This works:
roslaunch crazyflie_demo teleop_ps3.launch uri:=radio://0/20/2M

This doesn't:
roslaunch crazyflie_demo teleop_ps3.launch uri:=radio://0/20/2M/E7E7E7E701
or this even..
roslaunch crazyflie_demo teleop_ps3.launch uri:=radio://0/20/2M/E7E7E7E7E7

(https://github.com/whoenig/crazyflie_ros)