Boring material again
An idea came to run the cameras at 640x240. Only horizontal resolution is required for depth. Vertical resolution can be lower by an unknown amount, still limited by altitude accuracy. Extremely fast, accurate altitude is required.
Besides that, attention turns to SPI & dual camera synchronization, not the high bandwidth world of video processing. SPI has to change directions & use DMA. That takes a lot of playing with finished hardware, since there's no multimaster SPI DMA example.
There were some ideas to have a timer on the right ARM drive the clock of the left ARM. There's resetting a timer on the left ARM at the start of every left frame. The timer value at the start of every right frame shows if it's ahead or behind.
There can be a delay state, where the camera clock is paused for a few loops. There aren't any easy ways to speed it up.
It might be possible to slightly slow down both to 65fps by adding a 1ms delay to the master. They could both pause their clocks after a frame. The master would trigger the slave to resume after 1ms. It could be an acceptable reduction in frame rate. That would reduce the position update rate from 35 to 32Hz. It's unknown what the minimum rate for stable flight really is. Overexposure from the delay is a real problem. It could overexpose the whole frame or just 1 random pixel.
Officially, the Rigol says the maximum is 68fps. The synchronized framerate would be 64fps.
There is a HSITRIM register which trims the ARM clock. The algorithm would be 1st measure the time between right eye frames. If it's too long, increase the clockspeed by 1. If it's too short, decrease the clockspeed by 1.
If it's in the bottom half of the left eye frame, increase the clockspeed by 1 if no change or revert if the change was -1. If it's in the top half of the left eye frame, decrease the clockspeed by 1 if no change or revert if the change was +1.
|All times are GMT -5. The time now is 11:25 AM.|