Go to Post FIRST is the most glorious test of the mind. Anyone can run a marathon or get a slam-dunk. It takes guts to admit you are a nerd that enjoys six weeks off non-stop stress, and actually thrives on it. - kws4000 [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rating: Thread Rating: 5 votes, 5.00 average. Display Modes
Prev Previous Post   Next Post Next
  #16   Spotlight this post!  
Unread 01-04-2014, 00:41
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Re: Network Tables

So it really seems as though you were in the same boat as me three weeks ago. There is one very easy fix to the problem you are fixing, but it requires kinda out of the box thinking
Through my VC++ opencv adventure, I learned that many processor intensive routines may have a such a low performance that the processing rate will become less than the capture rate. I believe I properly understand your setup. You are using an MJPEG stream with VideoCapture. I have two solutions available for you that should be relatively easy to use.
If you must stay with the network MJPEG stream approach,
--Decrease the capture rate of the camera to the MAX rate that your vision software will run at. This will cause you to economize on your lag and if for some reason the software runs a bit faster, it will just wait for the next frame.
--THREAD YOUR GRABBER
The second option is what saved me. I was before getting 30 seconds of lag even though I was running at 5fps. What this will do is run the grabber parallelly. I believe you are pretty decent at C++ so you should be able to figure it out. Try <thread> and <mutex>.
So what you want to do is wait for the next frame to be available from the camera and download it immediately. Do not do this in the main Mat because it will make the entire program wait and brick up your effort. After the frame grab, send the data to the actual processing Mat. In your processing loop, copy over that global Mat into a local Mat so the system can free the resource as quick as possible! Then, perform the operations you want to do. This way, the old frames are constantly deleted as new frames are available
Try to use both the following together. Using just the first option will make no difference. Using both options is when you get both efficient and get rid of the lag.

I have been paying attention to your posts lately and I believe you have a PandaBoard. Snag an inexpensive USB webcam and that should eliminate most of the lag you are experiencing!

I just gave you my two cents, so good luck!


Also, you might find it easier to implement a UDP bidirectional socket instead of NetworkTables. There are libraries for this in C++, Java and even LabView!
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 02:01.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi