VL53L4CX Dealing cleverly with multiple object ranging

[MGG]

Hi all, I'm back with another question re: our 5-TOF setup (VL53L4CX x 5, all 'looking' out of the centre of a spherical sculpture, trying to detect and interpret people approaching and interacting with it).

I posted earlier about trying to multiplex these 5 sensors to avoid crosstalk, and that sort-of-worked but introduced enough lag that it wasn't worth it -- we have carefully managed the positioning of the cones and I don't think we are getting much crosstalk, or at least, once we started throwing out rangeStatus 4, 12, and 11 we got pretty good results.  We are basically only using rangeStatus 0 readings now.

Further note: we are looking for targets at about .75-2.5m, so right at the edge of where these results seem reliable.

My question is:

I'm seeing a bit of 'bouncing' where on one read a sensor will report 2 targets, then just one, then back to 2... since we're only taking the 0 rangeStatus readings, I'm going to assume that it's basically having trouble confirming a second or third target, and the distance readings are fluctuating between those for the returned targets.

Right now our code is designed to take the closest target as the 'best' but that gets problematic if the object keeps jumping back and forth, essentially disappearing for short blips.   Can you suggest a good technique for either: setting the ranger to only pick one object?  or ensuring that the returned objects are reported consistently in the same order i.e. object[0] is always the closest and we can ignore the others?  ... or is there another way of dealing with this kind of transient jumping re number of objects?

I'm casting about here, going to try a bunch of things in my code to smooth, interpolate, average... but wondering if there's a clever way to deal with this already, perhaps in a setting I've overlooked?

PS: just discovering all the tuning_parameters.... a bit overwhelming, but more to try here as well I guess!

FYI this is a sketch of our basic setup for these TOFs

Thanks

<M>

[John_Kvam · Accepted solution]

With the histogram processing on your VL53L4CX (or the VL53L1CB) you can detect two targets provided they are both detectable and 80cm apart in distance. If the two targets become closer together you get a 'merged target'. This has it's own 'error' code, although it's really a warning - telling you you have multiple targets too close to resolve separately.

You can order the targets to be the 'strongest' or the 'closest' first. Generally, given the way the light spreads with distance, the closest is the strongest, but not always. A far, reflective target could outshine a closer dull one.

Did you configure the order as closest first?

But if you get two of them, you could re-order them if that makes sense to your system.

But here is the real issue... There is always going to be a limit. And if a target is very close to the limit, you are going to see it sometimes and not other times. ST calls this 'flicker'. (I would have said 'We call it flicker', but I've retired.)

Flicker is hard to deal with. But one approach is to ignore targets until the signal is pretty strong. By default you need 0.5M counts per second, but you might want to increase that to ignore targets until you are sure they are solid.

It's all I can think of. Anyone else?

- john

[MGG]

Thanks John - flicker is indeed how this appears.

Since writing this, I've found the extraordinary vl53l4cx_tuning_parm_defaults.h and its myriad and somewhat opaque parameters.... most of which probably won't help me, but I'm wondering if there's a more comprehensive guide than sections 5.3.2 and 5.3.3 of ST's UM2923 guide ?   So many things to tweak, potentially (including the 

VL53L4CX_TUNINGPARM_HIST_TARGET_ORDER_DEFAULT that you mentioned).

I'll also try messing with the signal strength looking for a minimum number of counts per second - I assume once I set that it will affect whether I get a '0' or a '12 (signal too low)' for these edge-cases?

Much appreciate your input, and also anyone else who has dealt with these potentially quick-moving, edge-case scenarios.  Thankfully it's an HCI application, so it doesn't have to be super-precise or accurate like a manufacturing process or an elevator...

Thanks again, I'll mark this as a solution but still hope to see more ideas if they're out there.

<M>