Arduino as timer for strobe light1/5/2024 We get an average time shift of about 56.6 µs per row. Rolling shutter row delay measurements at various exposure and flash duration. Fixed exposure of 300 µs, varying flash duration 500 µs, 1000 µs, 2000 µs.Ī few measurements are summarized in the following table: Each time we restart the camera the stripe will be at a different location, but it stays put.įig. Here are some captured frames with fixed camera exposures and varying LED flash durations. We should now have everything needed to compute the rolling shutter time shift. It is a meaningless value in itself and we are not going to convert that back to a framerate. The stripe stabilized when I settled on 33376 µs. Manually bisecting the values until the stripe is stable is also quite feasible in practice. The stripe is moving upward, meaning that for each frame, we fall a bit short, and the flash is happening at a lower time coordinate in the frame interval, illuminating higher rows.Īt that point I added a potentiometer (plus code to average its noisy values) and linked it to the blinking rate, so that I could more easily fine tune to the actual camera framerate. As long as we can somehow tune to it and stabilize the stripe, we do not need to know its exact value. So our blinking interval is slightly off, but fortunately it does not really matter for our experiment as we are not trying to measure the camera frequency itself. For our purposes, the difference between, say, 30.00 fps and 29.97 fps is about 33 µs which is well under the board capabilities. It suffers from drift and cannot be used if long term accuracy is required. Either the camera is not really capturing frames at 30 fps like it advertises, or the Arduino clock is not ticking exactly 30 times per seconds, or a bit of both.Īrduino’s micros() has a granularity of 4µs but it is definitely lacking in accuracy. A stripe corresponding to the few rows that were exposed during the LED flash… But slowly moving up. Stripe of illuminated rows, with strobing frequency mismatch. First attemptĪfter configuring the camera to 800×600 30 fps, and the Arduino to blink the LED for 500 µs every 33333 µs, we get a nice Cylon eye stripe:įig. The LED with the diffuser is crammed close to the camera lens to get as much light as possible from the flash. Logitech drivers expose a vendor-specific property with the adequate control of exposure. Furthermore the usual DirectShow property does not always map precisely to the firmware values. Note that not all camera have a control for exposure duration. On the camera side, I manually focused to the closest possible, and set the exposure time to the minimum possible, which is 300 µs on the Logitech C920. The diffuser is simply a piece of Styrofoam 2 cm thick, with the LED head stuffed in about 5 mm deep (works better than a ping pong ball).Īll timing relevant code in the Arduino is done using microseconds (more about accuracy below). For this I’m using a large LED (10 mm) and a diffusion block. Experimental setupĪs we are going to count pixels on the resulting images we want the clearest possible differentiation between lit rows and unlit rows and we want the entire row to be lit. Considering we know how long each row in the stripe has been collecting light and how long the flash lasted, we can compute the total time represented by the rows and derive a per row delay. We limit the flash duration to reduce the stripe of rows catching it, and we measure the height of the stripe in pixels. The principle is simple, we align the LED blinking frequency on the camera framerate so that exactly one flash happens for each captured frame. ![]() Rolling shutter model with a flash of light happening during frame integration.Īn Arduino can serve as a cheap stroboscope for our purpose. So if we flash a light for a very short time in an otherwise dark environment, only the rows that happen to be exposed at that time are going to capture it.įig. Each row is properly exposed as configured, it’s just that the start of the exposure of a given row is slightly shifted in time relatively to the previous one. The exposure duration is independent from the rolling shutter. ![]() Rolling shutter artifacts when imaging a propeller.īut beside the visual distortion, can we quantify how severe the problem is? Let’s find out with a simple blinking LED. Basically the only bright side is that it makes propellers and rotating fans look funny.įig. This is definitely a problem when using these videos for measuring object velocities or for camera synchronization. It follows that the various parts of the resulting video image do not exactly correspond to the same point in time. In a rolling shutter camera (most USB cameras), the image rows are exposed sequentially, from top to bottom.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |