groupgets / purethermal1-uvc-capture

USB Video Class capture examples for PureThermal 1 / PureThermal 2 FLIR Lepton Dev Kit
125 stars 81 forks source link

PureThermal unstable fps #3

Closed andreionutz closed 6 years ago

andreionutz commented 7 years ago

Hi, I have some pure thermal modules that I use to get Y16 raw data with OpenCV/DirectShow on Windows. Everything works fine, apart from the fact that I have a variable acquisition time resulting in a frame rate of ~6.6fps. This is reproducible with the pt1-v4l2-grab (I removed the saving) on Ubuntu 14.04. Can anyone confirm this? Regards, Andrei

kekiefer commented 7 years ago

Here's what frame rates look like in GetThermal:

Elapsed: 120.038000
Elapsed: 119.967000
Elapsed: 119.872000
Elapsed: 99.978000
Elapsed: 120.200000
Elapsed: 119.975000
Elapsed: 220.328000
Elapsed: 119.688000
Elapsed: 119.825000
Elapsed: 120.128000
Elapsed: 220.065000
Elapsed: 119.888000
Elapsed: 240.106000
Elapsed: 120.026000
Elapsed: 99.931000
Elapsed: 120.025000
Elapsed: 239.994000
Elapsed: 99.879000
Elapsed: 119.926000
Elapsed: 120.172000
Elapsed: 120.149000
Elapsed: 119.881000
Elapsed: 99.806000
Elapsed: 240.203000
Elapsed: 119.979000
Elapsed: 219.954000
Elapsed: 120.121000
Elapsed: 119.761000
Elapsed: 120.032000
Elapsed: 99.960000
Elapsed: 120.152000

So there is a little jitter, but this doesn't seem catastrophic. Are you seeing worse than this?

I suspect this jitter comes when the Lepton frames are coming in and getting prioritized over the USB transfer work.

I guess one thing that will hang the transfer up for a second or so is an auto FFC in shuttered camera models. Particularly if ambient temperature is changing a lot, this can happen somewhat frequently. There is a CCI command to disable this feature that you can send via UVC or modify the firmware.

andreionutz commented 7 years ago

the timings that you posted average to ~138ms per frame, that makes ~7.25fps. it's a bit better than what i see (~6.6fps), but it's still way under the 9fps expected. Also, it's normal to expect a jitter for a USB cameras, but in 10s of ms rather than 100s. your measurements are: 99-120-220-240ms per frame, i also get 360ms sometimes. i would say 20ms is a jitter, 120ms is a lost frame.

can you make the same measurement with the SPI interface - I don't have this option. The problem might still lay to the USB controller.

I take care of the auto FFC, so that's not an issue.

espadolini commented 7 years ago

I'm getting the same problem here, with the Y16 firmware and a radiometric lepton "2.5"; specifically, i'm not getting anything better than 7 fps. I measured this with ffmpeg and guvcview.

espadolini commented 7 years ago

Just to be clear, I also tested the frame capturing with the lepton breakout board, and I'm getting the full 8.7ish fps.

kekiefer commented 7 years ago

I've been doing a little digging and I'm still not sure exactly where this jitter is coming from. It must have something to do with the synchronization between the two tasks to transfer usb data and download from the camera (which it does somewhat simultaneously).

One thing I did find though, is that if you remove the artificial/non-telemetric frame rate limiter here: https://github.com/groupgets/purethermal1-firmware/blob/master/Src/lepton_task.c#L146 then you'll see the full 26 fps, duplicate frames and all. This really cuts down on the latency too since you're guaranteed to see the new frame as soon as it comes in.

edit: I haven't tried this with Y16, obviously this line would do nothing, but I would suspect the duplicate frame check based on telemetry could also be removed to the same effect.

espadolini commented 7 years ago

Is this something that should be filed in purethermal1-firmware?

espadolini commented 6 years ago

@kekiefer, did you test if this was fixed in the development branch of groupgets/purethermal1-firmware?

kekiefer commented 6 years ago

Since PT1 version 1.0.0, data acquisition has been reworked and shouldn't be dropping frames anymore.