Quote:
Originally Posted by Greg McKaskle
The BMP capabilities on the camera are interesting to look at. What I found was that the time to transmit the much larger file added a delay comparable to the decompression time. You really don't need to worry about the overhead of the http session. The LV camera VIs use the JPEG cgi and do that currently, and the overhead seemed miniscule.
Greg McKaskle
|
More so than the HTTP session I'd be worried about the connection creation/destruction each time. Since the the camera literally streams JPEGs pushing them once every time it gets a new image to the connection, it maintains the same connection throughout. Connecting is one of the largest overheads in network systems (when you consider the camera is running a server that probably allocates memory for each call when it's made, etc., slowing things down). Although I do suppose it's all NULL due to the transmission delay on bitmaps as you say. I might investigate this myself later, but only after the base code does everything I'd like it to :-)
Another possibility for speeding it up would be to remember the position of the target between images, and use that as an estimate for where it will be the following time. If you get the cycles fast enough, it shouldn't move too much in between (or, you could even add a simple first-order approximation of position based on current and previous positions). Then find the particles within 50 pixels of the previous spot or such. I'm not sure if it's possible to force cropping on the camera side, but that'd possibly be handy - although, again, probably force constant re-connection (I don't know if the camera supports keep-alive connections. Although it does have a scripting interface...)
Another fun improvement might be to sync the servo movement up with the camera, so that pictures are returned a little less blurred. Or use a gyro to counteract turning of the robot automatically, also lessening blur.
If you wanted to go _really_ in depth, you could take the cropping idea above to a whole second level, and write your own JPEG code to only decode the blocks of the image that you think the target would be in (IIRC from the file format, you'd still have to go through the huffman encoding for the entire image, but you could do the IDCT and such only on the parts you need).
There are literally tons of things I'd like to explore to try and speed up this code. Although, for those interested, my first attempt is going to be to get libjpeg compiled for this processor and see if it's able to decode any faster (although for all I know, NI's JPEG code could easily be based on it, and I'm wasting my time - research is to be done).