"Unless you get into custom high-speed cameras or sensors, it takes over 15 mS to capture an image (60 Hz video), plus whatever processing time you incur."
This is a typical real time example. If assumption is made one CPU is used built into a micro with peripherals or not and same processing is required for all images. Dead line will be equal to period which is one of basic requirements for http://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling and http://en.wikipedia.org/wiki/Rate-monotonic_scheduling schedulers. These schedulers also happens to be optimal under some assumptions so they should be rather important. How important dead line is not missed is a little bit different matter. For a recieve buffer in serial communication it must be kept unless data should be lost, it may however be resent again. For a servo loop I guess one missing update or extra delay sometimes will not matter to much for most cases in real life although it degrade of course degrade performance at least theoretically. Nicklas Karlsson On Wed, 08 Oct 2014 08:40:16 -0500 Charles Steinkuehler <char...@steinkuehler.net> wrote: > On 10/8/2014 8:25 AM, Ralph Stirling wrote: > > Running OpenCV code in a real time thread would be an entirely different > > matter, I suspect. I do not know if the cv2 library would be compatible > > with real time requirements, or what level of processing could be > > accomplished > > in a reasonable fraction of a servo period. You would also need to think > > carefully about what camera you use. I used a USB2 microscope camera, and > > I suspect USB2 would be entirely incompatible with the realtime > > requirements. > > Perhaps some PCI bus board with internal frame buffer could work, if OpenCV > > could talk to it. I normally just get UVC compatible cameras, but those > > are all > > USB2. > > Unless you get into custom high-speed cameras or sensors, it takes over > 15 mS to capture an image (60 Hz video), plus whatever processing time > you incur. That said, folks have done some pretty amazing things within > the limitations of standard video and camera systems (sampling at a > specific point in time and using the calculated "where we were" to > update the "where we're going" sometime later after a significant > processing delay while the system is still moving). > > > If you wanted to really get into it, you could work with the machinekit > > fork, > > and use the Parallella board as your platform. That has a 16 core (or 64 > > core) > > processor that has had OpenCV ported already. There is also a Xilinx fpga > > (which contains two Arm cores that run Linux) that could be used for CNC > > tasks. I have one sitting on my desk, but don't know when I'm going to > > have > > time to play with it. There would still be the matter of camera > > communications. > > Altera has similar parts I'm playing with for work. Dual-core ARM > Cortex A9, PCIe, and big chunks of FPGA. I'm very interested in getting > the HM2 VHDL code running on this device, but no so concerned with > OpenCV (even though I already have hardware to run HD-SDI video via the > high-speed transceivers). Just not enough time for all the cool > projects... :) > > -- > Charles Steinkuehler > char...@steinkuehler.net > ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
