TOF on ae3 is working eratic

OpenMV Boards
1

I have a openmv ae3
and I am trying to use the tof, it’s very nice that is possible to mesure in different directions
but there is a 50 50 chance of success
the initialization of tof works sometimes
can one catch it with error handling or are there other alternatv
My experimental code:

import tof
import time

tof.reset()
time.sleep_ms(3000)
tof.init(1)
time.sleep_ms(2000)

# while True:
    # get dist
    # depth = tof.read_depth()

while True:
    try:
        # get dist
        depth = tof.read_depth()
        for pos in range(64):
            print("pos nummer:", pos)
            print(depth[0][pos])

    except OSError:
        # The sensor can occasionally fault on a specific frame read.
        # If it drops a packet, reset the stream buffer and continue.
        tof.reset()
        time.sleep_ms(2000)
2

Which firmware version are you on and can you paste the exact exception text? All of the ToF fixes for the AE3 are in v5.0.0 and later. Two things in your script: the module raises RuntimeError, not OSError, so your except never runs. Also, tof.init() already power-cycles the sensor, so the tof.reset() and the sleeps before it aren’t needed. Try:

import tof
tof.init()
while True:
    try:
        depth, dmin, dmax = tof.read_depth()
        print(depth)
    except RuntimeError as e:
        print("tof error:", e)

We’ve also made init and ranging more tolerant in the next release.

Please do Tools->Install the Latest Deve release to get the latest firmware on the AE3.

3

Thanks kwagyeman

I have firmware 5.0.1
It’s work fare bether but there is an runtime error some times

image.png
image.png482×413 20.4 KB

4

I’ve pushed many fixes to ToF recently, mainly to address recovery and stability (it was much worse before). However, the intermittent ToF failures still happen and they’re expected (hardware thing really, see below), so you should just ignore them just like the examples do:

    except RuntimeError:
        continue

The driver auto-recovers from this and the next frame should be captured successfully. The reason why it occasionally fails is that sometimes a read overlaps the sensors frame write to its internal buffer (it’s not double-buffered), so the driver finds a mismatching header and footer in one frame and reports a corrupted frame (called GO2 errors). When this happens I retry a read only once, if two frames are corrupted in a row it raises an exception. Perhaps there’s room for improvement here, like retry more times with a backoff/random delay.

5

Thanks
Is it possible to include tof.inith() in the error handling?

6

It’s not needed, the driver automatically resets/recovers on error, before raising, you’d just be slowing it down by doing it twice. Note we’ve made a couple more small fixes to improve things further. Please give the development firmware a try, if you like.