Hi everybody,

I'm a student from university of L'Aquila and I'm using the crazyflie 2.0 with the flow deck for a project.

I'm trying to get data about deltax and deltay using the flow deck with the LogConfig. I obtain my data (stateEstimate.x, stateEstimate.y, stateEstimate.z), but I have a problem. When I see stateEstimate.x, it is equal to 0.5 even if the crazyflie moves only on z axis. For this reason, I am not sure about measure unit of deltax and deltay obtained from the flowdeck. Is it possible that deltax obtained by flow deck is equal to 0.5 meters when the crazyflie doesn't move on x axis?

Could someone help me?

Thanks,

Anastasia

## measure unit for detax and deltay obtained by flow deck

### Re: measure unit for detax and deltay obtained by flow deck

Hi and welcome.

What you are measuring is the Crazyflie absolute X position. In the case of the flow deck this is an integration of the Crazyflie velocity calculated from the delta_x/delta_y data from the flow sensor. So what you are observing makes sense. If you where looking at the deltas you should get something around 0.

You can get the deltas directly from the flow sensor in the variables motion.delta_x, motion.delta_y: (I am moving the Crazyflie in a circle motion above my keyboard in this example).

More generally, I would advice to look at the log variable available and display them in the client first (like I did there), this allows to quickly check what the data looks like.

What you are measuring is the Crazyflie absolute X position. In the case of the flow deck this is an integration of the Crazyflie velocity calculated from the delta_x/delta_y data from the flow sensor. So what you are observing makes sense. If you where looking at the deltas you should get something around 0.

You can get the deltas directly from the flow sensor in the variables motion.delta_x, motion.delta_y: (I am moving the Crazyflie in a circle motion above my keyboard in this example).

More generally, I would advice to look at the log variable available and display them in the client first (like I did there), this allows to quickly check what the data looks like.

### Re: measure unit for detax and deltay obtained by flow deck

Thanks arnaud for your reply,

ok I've tried to read deltax and deltay from the client and all it works. But I'd like to know where the integration used to obtain x absolute position is calculated in the c code .

I mean in what c function delta x and delta y are taken from the flow deck and used in order to obtain x and y absolute position.

ok I've tried to read deltax and deltay from the client and all it works. But I'd like to know where the integration used to obtain x absolute position is calculated in the c code .

I mean in what c function delta x and delta y are taken from the flow deck and used in order to obtain x and y absolute position.

### Re: measure unit for detax and deltay obtained by flow deck

Hi, the integration is happening in the Kalman filter (EKF). I am no expert but it looks like the integration is happening there: https://github.com/bitcraze/crazyflie-f ... #L685-L693 in the predict function.

The deltax/deltay values are used by this function to update the velocity estimation in the kalman filter: https://github.com/bitcraze/crazyflie-f ... 1002-L1066.

The deltax/deltay values are used by this function to update the velocity estimation in the kalman filter: https://github.com/bitcraze/crazyflie-f ... 1002-L1066.

### Re: measure unit for detax and deltay obtained by flow deck

I wanted to ask some other questions about the inner workings of velocity estimation from the flow deck.

1. Where was the number of pixels obtained? Here I see NPix = 30, but I can't find this information anywhere within the PMW3901 datasheet here.

And is NPix the entire length of the picture or half the length>

2. How does this line work?

predictedNX = (flow->dt * Npix / thetapix ) * ((dx_g * R[2][2] / z_g) - omegaFactor * omegay_b);

My guess is dx_g * dt gets you the x displacement, and Npix/(thetapix)(z_g) gives you the physical length (in meters?) of a full screen of pixels. Thus, the two numbers times each other gives you the number of pixels displaced, but I don't understand how the one value from the rotation matrix and the omega variables factor into that.

1. Where was the number of pixels obtained? Here I see NPix = 30, but I can't find this information anywhere within the PMW3901 datasheet here.

And is NPix the entire length of the picture or half the length>

2. How does this line work?

predictedNX = (flow->dt * Npix / thetapix ) * ((dx_g * R[2][2] / z_g) - omegaFactor * omegay_b);

My guess is dx_g * dt gets you the x displacement, and Npix/(thetapix)(z_g) gives you the physical length (in meters?) of a full screen of pixels. Thus, the two numbers times each other gives you the number of pixels displaced, but I don't understand how the one value from the rotation matrix and the omega variables factor into that.

### Re: measure unit for detax and deltay obtained by flow deck

Hi,

1. This was originally found experimentally. We get unit-less tick from the sensor, we assumed it was delta in pixel, and with the rough knowledge of the viewing angle we could estimate the number of pixel on the sensor by moving the sensor a certain distance. The same experiment also allowed us to refine the viewing angle.

2. I cannot explains the details without looking further (this line was written, not by me, quite long time ago), but I know what it should do: the number of pixel displaced on the image is affected by the velocity of the sensor, the distance to the ground (z_g is the height) and the rotation of the sensor. If the sensor rotates, what it sees of the ground is going to move. This line is calculating the movement in X that we should have according to the current state estimation.

1. This was originally found experimentally. We get unit-less tick from the sensor, we assumed it was delta in pixel, and with the rough knowledge of the viewing angle we could estimate the number of pixel on the sensor by moving the sensor a certain distance. The same experiment also allowed us to refine the viewing angle.

2. I cannot explains the details without looking further (this line was written, not by me, quite long time ago), but I know what it should do: the number of pixel displaced on the image is affected by the velocity of the sensor, the distance to the ground (z_g is the height) and the rotation of the sensor. If the sensor rotates, what it sees of the ground is going to move. This line is calculating the movement in X that we should have according to the current state estimation.