Communication issue with Crazyflie

Discussions about all things Bitcraze
PhilipH
Beginner
Posts: 8
Joined: Tue Jun 27, 2017 9:11 pm

Communication issue with Crazyflie

Post by PhilipH »

Hello,

Our team has been working with flying Crazyflies using the crazyflie_ros package from whoenig. We use Vicon in our lab to get the position data of crazyflies and send them onboard using the external_position topic provided in the ros package. We are also using posSet mode and sending waypoint commands onboard so that we can fly with the onboard position controller in the firmware.

We are able to regularly establish a connection with crazyflies and read imu/battery data/etc using crazyradio.

However, when starts publishing external positions to the drone, we start to experience communication issues. Most of the times, after we establish a connection, crazyflie seems to have problems receiving both the external positions and command waypoints at the same time, and it will not takeoff. If we stop sending external positions, then crazyflie will be able to takeoff(although not flying properly). If we use the UWB loco positioning deck and just send waypoint command (so no external_position from vicon), then crazyflie can receive commands and fly as expected.

We suspect the issue may be that crazyradio could not handle sending both external positions and command waypoints at the same time. Sometimes we got lucky and were able to fly even up to 3 crazyflies at the same time(using 2 radios) very smoothly, but most of the time it does not even take off. We tried changing address, bandwidth, channel and even computer and crazyradio, but could not produce different results.

Thank you for your advice and help.

Philip
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Communication issue with Crazyflie

Post by arnaud »

Hi Philip,

At which rate are you sending the external position and setpoints?

There is a limitation in the Crazyradio USB implementation that prevents sending and receiving more than 1000 packet per seconds at 2M (should be 1000 up and 1000 down), this limitation can be made worse if you change settings between packets (for instance keeping the copters on same channel but different address should help).

We have seen good results sending external position at 100Hz and setpoint at about 20Hz, but this was with only one Crazyflie.

The Crayswarm project (http://crazyswarm.readthedocs.io) is using broadcast packets and float16 numbers to send position to multiple crazyflie in the same packet. If you only have 3 Crazyflies this might not be needed yet but if you plan to fly more it could be a good idea looking at the Crazyswarm project.
PhilipH
Beginner
Posts: 8
Joined: Tue Jun 27, 2017 9:11 pm

Re: Communication issue with Crazyflie

Post by PhilipH »

Hi arnaud,

Thank you for your reply. In fact, our team did some tests today, and here are the results.

We were sending both waypoint commands and external positions at 70Hz, which we believe would not reach the 1000 packet/sec limit. We were able to consistently fly 1~2 crazyflies with 1 crazyradio if we attached the UWB locolization deck and set up UWB anchors properly. If we disconnected either the UWB anchors or the UWB decks, things became inconsistent(basically sometimes crazyflie could fly but sometimes not). Since we have been using the TDoA UWB mode, we also had trouble flying if we flashed the crazyflie firmware without enableing TDoA in the config.mk file.

Thus, we found that UWB loco positioning system needed to be fully set up(firmware, nodes, deck) for external positions and command waypoints to be received consistently. I am wondering why would that be the case and is there ways to avoid using loco positioning system?

Thanks in advance,

Philip
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Communication issue with Crazyflie

Post by arnaud »

Hi,

This is not supposed to be the case, just last week we have flown the crazyfie in a mocap without LPS (https://www.youtube.com/watch?v=3lDvWlbDSOA) and it worked quite well.

Are you sure that you have the kalman filter enabled in your build? In the very latest version of the firmware the kalman filter is only enabled if the loco positioning deck is detected.

One thing to debug is to look at the position estimated by the kalman filter using the log (the log variables are https://github.com/bitcraze/lps-ros/blo ... launch#L24). I have already seen this EKF getting in a bad state where x/y/z are NaN, maybe this is what is happening in your case?
PhilipH
Beginner
Posts: 8
Joined: Tue Jun 27, 2017 9:11 pm

Re: Communication issue with Crazyflie

Post by PhilipH »

Hi,

Thank you very much for your explanations and advice. We have set ESTIMATOR=kalman in the config.mk file, and we send external positions without using any lps deck or nodes. Does that mean kalman filter will not be enabled?

We also looked into the log_kfpos topic, and x,y,z did become NaN. We knew that vicon position data was sent onboard and enqueued. However, when

Code: Select all

void estimatorKalman(state_t *state, sensorData_t *sensors, control_t *control, const uint32_t tick)
is called, the function

Code: Select all

static void stateEstimatorUpdateWithPosition(positionMeasurement_t *pos);]
from https://github.com/bitcraze/crazyflie-f ... man.c#L483 would turn the pos.x/y/z into NaN.

Ideally, we would like to be able to fly without lps nodes/deck attached. Is there other ways to enable kalman filter and pass the Vicon external positions into the filter properly?

Philip
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Communication issue with Crazyflie

Post by arnaud »

If you set ESTIMATOR=kalman, then the Kalman filter is activated, one proof is that you get NaN in positions: this is the Kalman filter mis-behaving. I have seen exactly the same behavior when using webcam as positioning: as soon as the Crazyflie entered the frame, the EKF went to X,Y,Z = NaN.

The video I sent used an unmodified firmware from ICRA, we just removed the LPS deck and sent position. So what you want to do is not only possible, it is the way it should work.

One extra thing we are doing is to reset the kalman filter before sending any setpoint. This is usually enough to recover from the NaN condition: https://github.com/bitcraze/crazyflie-l ... y#L99-L105.

In ROS you should be able to reset the EKF with (untested code!):

Code: Select all

    rospy.wait_for_service('update_params')
    update_params = rospy.ServiceProxy('update_params', UpdateParams)
    
    rospy.set_param("kalman/resetEstimation", 1)
    update_params(["kalman/resetEstimation"])
    time.sleep(0.1)
    rospy.set_param("kalman/resetEstimation", 0)
    update_params(["kalman/resetEstimation"])
PhilipH
Beginner
Posts: 8
Joined: Tue Jun 27, 2017 9:11 pm

Re: Communication issue with Crazyflie

Post by PhilipH »

Hi,

Thank you very much for your help! We solved this issue by just resetting kalman filter in ROS, and we even got some good results flying two crazyflies at the same time with one dongle!

We are also planning to adapt some techniques crazyswarm for controlling multiple drones. I will keep you updated for our progress :)

Philip
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Communication issue with Crazyflie

Post by arnaud »

Great that it works, I am eager to hear some updates :-).
mlac
Beginner
Posts: 5
Joined: Tue Mar 20, 2018 5:31 am

Re: Communication issue with Crazyflie

Post by mlac »

Hi,

I am having a similar problem. Whenever I try to send external position, the quad is restarting. In my python client, I am sending external position as follows: `cf.loc.send_extpos([0, 0, 0])`. If I remove this line of code, the quad does not restart.

I am not using loco positioning system. I wonder if this is an issue with the kalman estimator as well. I am not using ROS however, and I don't know how to setup the Kalman filter from the python client.

Any help is appreciated!
Regards!
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Communication issue with Crazyflie

Post by arnaud »

Hi @mlac,

Can you create a new topic with a bit more information about your exact setup? This would keep this thread focus on the original discussion. Among other things it would be useful to know what firmware you are running.
Post Reply