Velocity output doesn't look correct (looks more like the corresponding acceleration curve)

[delfy22]

Hi,

I'm using the Crazyflie as a positioning system for a larger drone (it's
currently strapped to the bottom) so we can use the Loco Positioning System
and Flow Deck for accurate position and velocity measurements. This mostly
works well after we've worked out a few kinks.

The problem I'm currently seeing is with the velocity measurements. 90% of
the time they're perfect, but occasionally when I move the drone the
velocity looks more like an acceleration curve than a velocity curve (see the attached pictures showing correct expected response, and the incorrect response).
CF velocity issue.zip

For example, I move the drone forwards quickly and then
stop. It should (and usually does) start at 0 m/s, rise to a peak, and drop
back to 0. However, occasionally something happens with the Crazyflie it
seems, and it then rises initially, drops to below zero and then rises back
up to 0. (looking more like the acceleration you'd expect, rising when it
starts moving, dropping to zero at maximum velocity, falling to a minimum
as the drone decelerates and falls back to 0 as it comes to a complete
stop.

It seems like once I restart the Crazyflie the issue disappears. Sometimes,
if I move the drone above a different surface it acts normally, then when
returning it to the original surface it acts strangely again. (This other surface does not always produce the correct behaviour however, only occasionally).

I wondered if it was stopping using the flow deck for whatever reason, but
running "read-ow.py" shows the flow deck still listed. Also, that and
"read-eeprom.py" both seem to show exactly the same output whether it's
acting normally or not.

We're using the Loco beacons in TDoA 3 mode (after struggling with this issue for a while #368). We're also publishing the position and velocity data to ROS using a modified version of the "basiclogSync.py" file, find attached. (Using kalman.stateX Y and Z, kalman_states.vx and y, and kalman.statePZ, as a sidenote, is there any difference between vx/y and PX/PY? It took us a while to find PZ as the kalman output Z velocity until I dug about in the crazyflie kalman filter code).
basiclogSyncROS_Drone.py.zip

I usually make sure to start the crazyflie in the same orientation as our Loco system, but will double check to see if starting it in other orientations causes the issue seen.

My next steps as suggested by Kristoffer are to:

• Look at the raw data from the flow deck using motion.deltaX and Y.
• Test what happens when blocking the camera, when issue is and isn't being observed.
• Double check what happens if I change the orientation on startup.

Thanks a lot in advance! If there's any other steps I can do, or any other information I can provide please let me know.

Henry

[delfy22]

Some updates:

• It looks like the velocity measurement is okay no matter what orientation I start the crazyflie in.
• When the camera is blocked I see the incorrect velocity, regardless of if it is blocked on startup or after, or what orientation the crazyflie is started in.

Maybe the crazyflie is occasionally stopping using the flow deck in its estimation for whatever reason, requiring a restart to begin using it again? I'll try and watch motion.deltaX and Y and see what this does when the issue occurs again.

[delfy22]

So I plotted the motion values when the crazyflie is behaving correctly and incorrectly which you can see attached.
DeltaXY.zip

It looks like when it's behaving unexpectedly, deltaX and Y are 0 so the flow deck isn't giving any information about its velocity? Interestingly deltaX and Y both vary when stationary as you can see, but they always stay at 0 when being moved. After a restart, the behaviour seems to match what I see when it is working correctly (although I can't really understand how the delta values correspond to the velocities, but at least they vary and are non-zero).

Are there any other tests you can suggest to see what's happening here?

Thanks a lot.
Henry

[krichardsson]

Hi!

I'm wonder if this is actually a communication problem with the optical flow sensor? There is a known issue (#368) in the SPI communication (also used by the LPS deck) that is not solved yet. It might be possible that it corrupts data going to the optical flow sensor or when reading?

One test that could be interesting would be to remove the LPS deck and see if you could reproduce the problem. It is possible, but unlikely, that your flow deck is broken, but if you can not reproduce it when the LPS deck is disconnected, it is likely related to #368.

[delfy22]

Hi Kristoffer,

Thanks for the suggestion, from memory I think we saw similar issues with the Loco and Flow deck not working together in TWR mode but when we changed to TDoA3 mode we no longer saw any crashes or issues with them working together.

As a quick update, I don't recall seeing this issue occurring for a while now, the Crazyflie seems to have been behaving recently. I've started turning it off after each use and restarting it when needed again rather than leaving on for long periods of time so potentially there's something there? I don't recall anything changing regarding the Crazyflie's software so I'm not sure what else has changed which might have affected it.

We're a bit pressed for time in our project at the moment so don't really have the opportunity to try and reproduce the issue again. Maybe it's worth closing the issue for now and posting any updates if I notice the behaviour returning?

Thanks again for your help with this.

[krichardsson]

Thanks for the suggestion, from memory I think we saw similar issues with the Loco and Flow deck not working together in TWR mode but when we changed to TDoA3 mode we no longer saw any crashes or issues with them working together.

Sounds plausible, TDoA3 is not using the SPI bus as much as TWR.

As a quick update, I don't recall seeing this issue occurring for a while now, the Crazyflie seems to have been behaving recently. I've started turning it off after each use and restarting it when needed again rather than leaving on for long periods of time so potentially there's something there? I don't recall anything changing regarding the Crazyflie's software so I'm not sure what else has changed which might have affected it.

I don't understand either why it works better, but I'm happy it does :-)

We're a bit pressed for time in our project at the moment so don't really have the opportunity to try and reproduce the issue again. Maybe it's worth closing the issue for now and posting any updates if I notice the behaviour returning?

No worries! You have already provided a lot of useful information. Thanks!

[delfy22]

Cheers Kristoffer, hopefully it was just a one off!