Lighthouse deck with v2 base station missing and freezing samples

[MSmeets94]

Hello all,

I have been experimenting with drone tracking using the lighthouse positioning deck using the crossing beam method. We are using the Crazyflie and lighthouse deck so we could get started quickly, but our final application will probably not. For this application we are probably limited to the crossing beam method.

I was wondering what the raw position data from the deck looks like, so I logged the X, Y and Z position to a file. After plotting the data, I noticed that there were periods in the logged data where the location of the drone is not changing.
The measurement setup is as follows:

Two Lighthouse V2’s mounted to the ceiling in a (roughly) 4 meter cubed volume like this:

LH1 is set to channel 1, LH2 is set to channel 2.

Drone sitting ~50cm above the floor on a rig to make the drone rotate around in a circle (diameter 75cm) with a rotational velocity of ~20rpm.

Drone:

• Hardware: Crazyflie 2.1 + lighthouse deck rev D1
• Firmware: 2023.06
• Lighthouse.method: 0 (CrossingBeam)

The log settings are as follows:

• Logger rate: 10ms
• Log topics: lighthouse.x, lighthouse.y, lighthouse.z

When the drone is stationary (IE the rig is not rotating the drone) the X, Y and Z data looks like this:

There are gaps in the data where the position is no longer changing. If I plot the time between consecutive changing samples for one minute, the plot looks like this:

When we zoom in on the band of sample times towards the bottom of this plot, we can see that most samples are taken within 20ms:

But sometimes the time between changing samples spike up to 400ms+. During this time, the X/Y/Z position is not changing anymore. However, the timestamps are still updating.

 
When the drone on our test rig is spinning around, the position signal looks like this, with even longer gaps in the data:

The plot of sample times now look like this:

So when the drone starts moving around, the time between samples becomes longer and the effective update rate drops. Our first impression was that these gaps were caused the lightbeams / sync pulses of the two light crossing. Something we expected because the sample time spiked in the first (stationary) example looked periodically. However, we cannot explain why this would become worse in a moving target, so this probably not the reason.

There are periods of 1000ms+ where no new position is being calculated.
 
When I log the output after the estimator, the spikes and glitches seem to disappear.
Before estimator:

After estimator:

I guess the missing data is filled in by the Kalman filter which is being augmented with data from the accelerometer/gyro. This also excludes any issues introduced due to logging.
I made sure that the sensors are not occluded by any objects. The lighthouses are visible by the position deck at all times during the rotation.
I tried recalibrating the setup multiple times and repeating the experiment, but this doesn’t seem to effect this issue.
Changing the channel assignment from 1+2 to 1+4 seems to effects the variation in sample time.
I replaced the lighthouse deck with another PCB, but this didn’t make any difference. The measurements after the kalman filter kind of exclude logging to be the issue here.

So I’m wondering why the position updating sometimes stop. Does anyone know why this happens?

[krichardsson]

Hi,
there are a few parts to explaining what you see:

I'm not exactly sure what data you plot in the position plots that freeze. What you see is most likely that the logged variables are not updated because no data is received, so this is basically a property of the logging system, there is no way to log "nothing". The "frozen" values will not be used in the estimator though, so it should not cause any errors.

There are four main reasons that data is not received

1. The rotor speed in the base stations is around 50Hz, but with a slight difference based on the base station channel. The reason is to avoid interference in the same spot all the time, but in stead you will see repeating interference. When there is interference, the lighthouse deck will not be able to decode the signal for a short period of time.
2. Something is blocking sensors or the angle to the base station is to shallow. Note that two or more sensors must be receiving the same sweep to be able to decode and use it.
3. There might be disturbances in the reception of the light from the base station that makes it impossible to decode the signal, sunlight for instance.
4. There is a know bug in the FPGA code that corrupts the data at certain angles. You can see this when turning the Crazyflie very slowly in one spot and logging data from the lighthouse deck.

In most cases loss of data for a short time is not a problem for flying, the kalman estimator will handle it. In general terms, the IMU should provide information for short term estimation, while the lighthouse system (or other absolute positioning systems) should add information for long term absolute position estimate. The estimator will work pretty well with an update rate from the lighthouse system as low as 5-10 Hz.