| Electronics > Projects, Designs, and Technical Stuff |
| Digital FPV video for drone racing |
| << < (23/28) > >> |
| TheDane:
--- Quote from: IDEngineer on January 22, 2019, 07:38:29 pm --- --- Quote from: TheDane on January 22, 2019, 07:19:14 pm ---I would say hardware wise, it is not impossible - it should be rather light, inexpensive, and easy to obtain. --- End quote --- Very promising, if the hardware can handle whatever processing is desired. Great way to prototype. This is great, except for the following. Many configurations run the NTSC camera output through the (separate PCB) flight controller, and then the flight controller outputs NTSC to the video transmitter. --- End quote --- Sorry to cut some of your quote - I hope it's ok. I have been working with the MinimOSD myself, a mix of an Arduino and the MAX7456 OSD chip. It didn't start out that way ^-^ http://ardupilot.org/copter/_images/MinimOSD_Micro.jpg If a SBC is used to generate video (it interfaces directly to a digital camera), what is stopping it from measuring other vital flight information (Gyro, Battery voltage, etc) - which is then superimposed onto the generated video image - which is then sent to the pilots FPV goggles. It is essentially a flight computer, capable of video+information handling - just like your existing system |
| TheDane:
--- Quote from: ogden on January 22, 2019, 07:45:50 pm --- --- Quote from: TheDane on January 22, 2019, 07:43:26 pm ---You're talking about the display INPUT, I presume The output is being outputted, until new information is stored in display memory - and the screen refreshed - showing the new output for a 'long' time, much longer than it took for the data to inputted --- End quote --- Before you spread your wizdom, make sure you got it right [edit] I talk about this BS where you supposedly tell your beliefs about how LCD works: --- Quote from: TheDane on January 22, 2019, 07:26:25 pm ---I hope you get where I am pointing at, as the screen has to be 'stationary long enough to show the entire picture', and then show the 'entire next picture long enough' --- End quote --- --- End quote --- How Not To Overclock: |
| richard.cs:
--- Quote from: Marco on January 22, 2019, 06:19:55 pm --- --- Quote from: richard.cs on January 22, 2019, 03:46:56 pm ---Because you can't use inter-frame compression (due to latency) --- End quote --- If you use 8x8 blocks, the only necessary latency is buffering 8 lines ... 0.19 ms at 720p60. --- End quote --- 8x8 blocks is intra-frame compression surely? Or have I got my terminology completely wrong here. What I meant was that most of the redundant information in a raw video stream is in the time domain, the parts of the image that either do not change from one from to the next or change only by simple translations. Any compression algorithm that accounts for that has to delay by a full frame, and a compression algorithm that doesn't can't remove the information that is redundant in time. Oh, I see what I missed. Because you're comparing your 8x8 block to the previous frame is does not introduce additional delay beyond waiting for 8 lines, or a little more if that block has translated vertically. Good point. |
| ogden:
--- Quote from: TheDane on January 22, 2019, 08:07:38 pm ---How Not To Overclock: --- End quote --- So what? That picture do not even apply to what we are talking about. Most LCD displays immediately show pixels as they arrive through interface. If you wonder what VSYNC and HSYNC signals are for - they are pointer/coordinate reset so both LCD and controller agrees where on the screen pixel contents will be going to. Watch YT video I mentioned |
| Kilrah:
--- Quote from: TheDane on January 22, 2019, 07:19:14 pm ---I do not know if the Raspberry Pi is good enough to handle video encoding at breakneck speeds --- End quote --- No it's not, there's a popular project using the combination of Pi+wifi and while it works it is not satisfactory in terms of latency. Main reason is that the whole video pipeline and GPU of the Pi is completely closed so there is nothing in there you can optimize, your only way through that is call the provided API function to get a frame from the "black box", with unnecessary buffering. Most SoCs on popular SBCs have the same problem of either closed libs and/or unobtainium documentation. --- Quote from: ogden on January 22, 2019, 07:39:06 pm ---So you say that LCD does not take picture sequentially? - Meaning controller takes whole frame into RAM, then frame miraculously in no time appears on LCD screen? :-DD Just searched YT for Arduino LCD topic to show how LCD update happens in slo-mo: https://youtu.be/X8syt55ITUo?t=267 --- End quote --- That's a small, low performance SPI module, you just populate its internal buffer in the order you want and at the speed you want. Normal fast high res displays (such as the ones with the common parallel 24bit RGB interface) of course take the data sequentially but also in order and at constant refresh rate, you can't just stop sending stuff while you wait for the next line or such, if you don't respect timings you get what is shown in the video above. The standard way that computers and display controller boards use is to hold usually 2 full frame buffers that are sent to the screen alternatively using DMA at the screen clock aka out of sync with the incoming data so that the controller can populate the inactive buffer while the other is sent to avoid screen tearing and artifacts, but that obviously introduces 1-2 frames of latency. Since the display panel is in the end the one that's driving the timing really minimizing latency would require lots of syncing so that the whole camera, encoder, transmitter and receiver work just right so the data arrives at the point where it is to be sent to the LCD as close as possible to the moment where it is to be sent to the display panel, with minimal buffering with only small FIFOs containing a fraction of a frame between each component instead of one or multiple frames. And some fast, logic-driven (hence FPGA again) that is capable of "filling in" the data to be sent to the display when a packet is missing at a small multiple of the pixel clock which is typically 25ns on a 800x480 panel. That's what makes it hard to use off the shelf stuff. Almost all of it just puts buffers between each step so as not to have to bother with that, and it's why you get >100ms latency with most standard camera->computer->RF->computer->display chains. |
| Navigation |
| Message Index |
| Next page |
| Previous page |