search

pimoroni / mlx90640-library

Python library for the MLX90640 thermal camera
https://shop.pimoroni.com/products/mlx90640-thermal-camera-breakout
Apache License 2.0
133 stars 84 forks source link

Python Library: Use main library instead of statically building main C #29

Closed 21347 closed 4 years ago

21347 commented 5 years ago

The experimental python library directly uses MLX90640_API.c by compiling it alongside the Python wrapper. This overrides the I2C_MODE setting and requires all Python code to run as root.

Additionally, the get_frame function seems to redundantly synchronize with the camera's framerate by waiting - which, in my test environment, practically halved the available FPS. I think that the main library already has all necessary code to wait for a frame to be ready, hence I propose to remove the explicit synchronization.

I have a fork of the code that fixed that issue, I could open a pull request if needed.

Gadgetoid commented 5 years ago

This looks like a decent approach, thanks for taking the time to point it out- I trust you've had success with the Python API? I've always struggled somewhat with this sensor, as evidenced by the fact we still seem to have chessboard artefacts vs other implementations which do not.

I'll be happy to review a PR. Incidentally I want to drop the "RPI" I2C stuff altogether, since it's completely redundant and remains broken on Pi 4 since it depends on the bcm2835 library which may never be updated.

21347 commented 5 years ago

Well, I've been using the (changed) Python API with a small Python-based TCP/IP server recording Frames at 8 FPS and serving them to network clients on a Pi Zero, and it's been running smoothly for a few days. Prior to that, I already had a second sensor connected to a different setup using my own port of the Melexis example code with more problems - so I'd take that as a success...

When I interpret the term "chessboard artifacts" correctly (getting only one subframe correctly with the other invalid/zeros, while the 1st also might not contain valid data all over), I saw them only with my own port using the bcm2835 lib and only if the receiving thread was blocked for too long. It's possible to provoke them when initializing to fast, too - but only for the 1st frame. Up to now, I didn't see them with this library and enough "headroom" in the I2C-Frequency setting vs. FPS. (There are other "chessboard" like artifacts when filming moving objects, but filtering those I think is not the job of a low level library)

The RPI-I2C driver can probably be removed, yes - it seems the bare Linux one is running smoothly. Initially I preferred the bcm2835 port, because it did not require rebooting when changing the I2C frequency, but I think I remember there were options to do that even without the lib, I just cannot find them at the moment... After all, I did change the default setting to I2C_LINUX...

I will create a PR in a minute. I might commit a few other changes as well after they prove to be stable (reporting I2C transmission errors back to Python instead of to the console, for example), but those are even more experimental...

Gadgetoid commented 4 years ago

Thank you- you’ve brought some much needed balance to a library that I’m working on in a near vacuum. It helps to have some other ideas thrown in the pot to stop me running rampant.

Gadgetoid commented 4 years ago

I believe this is fixed (or, should I say improved?) as of merging your PR. Thank you.