Closed jameszah closed 2 years ago
Solution over here; https://github.com/espressif/esp32-camera/issues/363#issuecomment-1042667693
Looks like it was a "feature, not a bug", introduced May 21, 2021, but didn't get to the Arduino world until esp32-arduino 2, late in 2021, and not much noticed until 2022.
https://github.com/espressif/esp32-camera/commit/8eb032a94e518257d6bdbefc6d4d77f64cbf6b77
/**
* @brief Configuration structure for camera initialization
*/
typedef enum {
CAMERA_GRAB_WHEN_EMPTY, /*!< Fills buffers when they are empty. Less resources but first 'fb_count' frames might be old */
CAMERA_GRAB_LATEST /*!< Except when 1 frame buffer is used, queue will always contain the last 'fb_count' frames */
} camera_grab_mode_t;
It defaults to filling all buffers with pictures (fb_count), and then giving them to you when you call fb_get. If you want the picture when you call fb_get, you have to change the parameter to CAMERA_GRAB_LATEST.
and on Arduino, no news ?
i had to make to two pictures to validade a updated image...
config.fb_count = 1; ?
@tcpipchip it already is in Arduino
Yes, thanks
its working, i can send a image to aws IoT, send to lambada, call the recokgnizer to extract text and send back to aws IoT
quick update:
The CAMERA_GRAB_LATEST does not actually give you the latest image when you call fb_get. If fb_count is 4, you still have to empty the queue of 3 old images. The images are only 80 ms (720p for ov2640) or 40 ms (vga on ov2640) old, so they are quite new, but still not the latest.
The big problem is CAMERA_GRAB_WHEN_EMPTY, when they could be hours/days old if your camera is sitting there waiting for activity.
You can check the time that comes with the image if it is critical https://github.com/espressif/esp32-camera/blob/f0bb42917cddcfba2c32c2e2fb2875b4fea11b7a/driver/include/esp_camera.h#L169
if fb_count > 1, you have to get and release all old jpegs to get the current image.
If CAMERA_GRAB_WHEN_EMPTY, then you could have images that are a week old (good for battery and keep camera/esp32 cool)
If CAMERA_GRAB_LATEST, then the camera and esp32 are running full speed and your oldest image is 3 x 40 ms = 120 ms (for fb_count is 3 and camera set to vga) so not that noticeable. (good for fast efficient video - but camera and esp32 might get hot)
There seems to be a problem with multiple fb_count buffers in 2.0.2. It appears similar to this issue https://github.com/espressif/esp32-camera/issues/309
The problem is that when you init() the camera it fills the buffers with 4 pictures (for fb_count = 4), and then the first 4 calls to esp_camera_fb_get() will deliver those old original pictures, and it will store a new picture. And then the new picture will sit there until 4 more calls to fb_get(). So you are always 4 pictures behind. If you are waiting for 1 minute for an event, and then you call esp_camera_fb_get() for a current picture, you will get a picture of whatever was happening a minute ago.
The easy work-around is to take 4 pictures to clear out the old stuff, but you are still getting the 4th oldest picture with a call to fb_get().
Switching to fb_count = 2, improves things so you get the continuous camera function, but you still have to discard 1 picture to make sure you have something recent after the camera has not be used for a while.
If you run the code below while taking pictures of a stopwatch, you will see the effect -- the pictures are stored on the sd card with a sequence number, and the time hhmmss of the picture - you can see the burst of 10 pictures that include 4 old and 6 new marked within the same second or two.
So maybe just use fb_count = 2, do 2 fb_gets if you are doing any delay between fb_get, and copy the picture out of camera storage to your own psram storage if you are saving it for later use.
This is Arduino 1.8.19 with esp32-arduino 2.0.2 for an ai-thinker esp32-cam module with an sd card and 2640 camera.