Go to Post Ha. Lavery's a genius. - Aignam [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

 
Closed Thread
Thread Tools Rating: Thread Rating: 5 votes, 5.00 average. Display Modes
  #16   Spotlight this post!  
Unread 31-03-2014, 23:17
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: Network Tables

Quote:
Originally Posted by lucas.alvarez96 View Post
James, that would be awesome! Please post the link as soon as you can. Thanks man!
Here
https://www.youtube.com/watch?v=nLmviNrMers

Shows a demo of everything... and in here is a link to the first forge... I'll include here for convenience:
http://firstforge.wpi.edu/sf/projects/smartcppdashboard

Now... this code is due for an update, but we are just about ready to head out to Lonestar regionals... so after that I may get the code all updated probably in the next two weeks, but in its current state it should get you going pretty well.

Here is a sneak peak of what the newer stuff can do (not yet checked in there): https://www.youtube.com/watch?v=fccxxlvMqY0
  #17   Spotlight this post!  
Unread 31-03-2014, 23:49
virtuald's Avatar
virtuald virtuald is offline
RobotPy Guy
AKA: Dustin Spicuzza
FRC #1418 (), FRC #1973, FRC #4796, FRC #6367 ()
Team Role: Mentor
 
Join Date: Dec 2008
Rookie Year: 2003
Location: Boston, MA
Posts: 1,102
virtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant futurevirtuald has a brilliant future
Re: Network Tables

I think he's talking about this: http://firstforge.wpi.edu/sf/sfmain/...rtcppdashboard

The opencv files should be structured something like so:

Code:
C:\Python27\opencv_ffmpeg2xx.dll
C:\Python27\lib\site-packages\cv2.pyd
I custom compiled my version of ffmpeg, but at this point I don't recall if I had to do something special to get MJPG support. I'll have to go find the source tree if I still have it...
__________________
Maintainer of RobotPy - Python for FRC
Creator of pyfrc (Robot Simulator + utilities for Python) and pynetworktables/pynetworktables2js (NetworkTables for Python & Javascript)

2017 Season: Teams #1973, #4796, #6369
Team #1418 (remote mentor): Newton Quarterfinalists, 2016 Chesapeake District Champion, 2x Innovation in Control award, 2x district event winner
Team #1418: 2015 DC Regional Innovation In Control Award, #2 seed; 2014 VA Industrial Design Award; 2014 Finalists in DC & VA
Team #2423: 2012 & 2013 Boston Regional Innovation in Control Award


Resources: FIRSTWiki (relaunched!) | My Software Stuff
  #18   Spotlight this post!  
Unread 01-04-2014, 00:17
sparkytwd's Avatar
sparkytwd sparkytwd is offline
Registered User
FRC #3574
Team Role: Mentor
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Seattle
Posts: 102
sparkytwd will become famous soon enough
Re: Network Tables

We had to install ffdshow as well to get loading from a file working on windows.
  #19   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!
  #20   Spotlight this post!  
Unread 01-04-2014, 11:31
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: Network Tables

Quote:
Originally Posted by yash101 View Post
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!
I am not sure of yash101's setup, but if UDP is used from robot to driver-station beware. It costs more bandwidth by nature... which shouldn't matter if it is a direct connection, but if the robot is receiving packets it will need a dedicate thread to listen to packets on startup, due to the VxWorks issue. This thread elaborates on that and also talks about a bug fix with the Network Tables.
  #21   Spotlight this post!  
Unread 01-04-2014, 12:55
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Network Tables

Quote:
Originally Posted by JamesTerm View Post
I am not sure of yash101's setup, but if UDP is used from robot to driver-station beware. It costs more bandwidth by nature... which shouldn't matter if it is a direct connection, but if the robot is receiving packets it will need a dedicate thread to listen to packets on startup, due to the VxWorks issue. This thread elaborates on that and also talks about a bug fix with the Network Tables.
I don't see how this can be true.

Assuming the data to send is the same size (which depends on implementation), UDP would in the real world send less data, as it never resends packets that failed. You are also sending images on the same ethernet link, so a few extra bytes or packets here or there really makes no difference.

In either case, you need a listener somewhere to read all of the packets from the buffer. Network Tables already created a thread to do this, with UDP you are doing it on your own.

In many ways, I prefer UDP sockets as it is very simple to implement (there are thousands of tutorials on the internet describing basic sockets), you can use a simple struct to organize the data, and a checksum to discard packets that are garbled in transit. No library required. In LV, you can do it super easily by flattening a cluster to a string and then unflattering it on the other side.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
  #22   Spotlight this post!  
Unread 01-04-2014, 13:05
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: Network Tables

Quote:
Originally Posted by apalrd View Post
I don't see how this can be true.

Assuming the data to send is the same size (which depends on implementation), UDP would in the real world send less data, as it never resends packets that failed. You are also sending images on the same ethernet link, so a few extra bytes or packets here or there really makes no difference.
I should post some benchmarks... I think I got the high band width from UDP because I used the DO_NOT_WAIT flag when creating the socket. So perhaps it would be less, but I have yet to see confirmation of that.

Quote:
Originally Posted by apalrd View Post
I don't see how this can be true.
In either case, you need a listener somewhere to read all of the packets from the buffer. Network Tables already created a thread to do this, with UDP you are doing it on your own.
Needing a listener somewhere is not the same as needing a listener that is on its own dedicated thread listening even at startup. When I first dinked around with UDP I used WinSock2 for everything, and could set the options as such where I didn't need to make a new thread... this was great and kept the code simple. I then transfer this same code to VxWorks and saw the fireworks... the driver station would repeatedly lose connection and get it back. The UDP buffer overflowed and corrupted the TCPIP packets.

So ... you don't need to have a dedicated thread if you are using WinSock2, but for VxWorks, and the original WinSock... you do.
  #23   Spotlight this post!  
Unread 01-04-2014, 13:48
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,113
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Network Tables

Quote:
Originally Posted by JamesTerm View Post
I then transfer this same code to VxWorks and saw the fireworks... the driver station would repeatedly lose connection and get it back. The UDP buffer overflowed and corrupted the TCPIP packets.

So ... you don't need to have a dedicated thread if you are using WinSock2, but for VxWorks, and the original WinSock... you do.
I believe you are ascribing the wrong cause to what you saw. VxWorks running on the cRIO has a single shared buffer for all incoming network communication, and that's what made your flood of UDP traffic get in the way of the TCP packets from the Driver Station. Under Windows, your UDP buffer was possibly overflowing and (correctly) discarding packets, but under Windows that wouldn't mess up network communication on any other ports.

You do need to read the incoming network data at least as fast as it is arriving, but there is no requirement for you to do it in its own thread.
  #24   Spotlight this post!  
Unread 01-04-2014, 14:23
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: Network Tables

Quote:
Originally Posted by Alan Anderson View Post
I believe you are ascribing the wrong cause to what you saw. VxWorks running on the cRIO has a single shared buffer for all incoming network communication, and that's what made your flood of UDP traffic get in the way of the TCP packets from the Driver Station. Under Windows, your UDP buffer was possibly overflowing and (correctly) discarding packets, but under Windows that wouldn't mess up network communication on any other ports.

You do need to read the incoming network data at least as fast as it is arriving, but there is no requirement for you to do it in its own thread.

What you say here is what I was trying to say more or less... WinSock2 handles the stress of neglecting to process the packets. It was indeed the neglect of processing the incoming packets that caused this symptom which I confirmed with Greg McKaskle, and Brian from team 118 also ran into this issue back in 2012. It may indeed be possible that you can make it where it doesn't have its own thread... you could implement some kind of hand shake solution or defer sending packets until Auton or Telop functions are being called. But these alternatives are messy implementation IMHO. NetworkTables on the other hand does not have these issues at all, and probably one of the main reasons I switched... that and the ease of use, where adding more variables manually in UDP is a real pain. I've included these UDP_Listener.h UDP_Listener.cpp for reference where I could macro switch from UDP to Network Tables... it was so much easier working with network tables that I dropped this whole interfacing design.
  #25   Spotlight this post!  
Unread 01-04-2014, 23:09
mhaeberli mhaeberli is offline
Registered User
FRC #3045
 
Join Date: Feb 2014
Location: Redwood City
Posts: 88
mhaeberli is on a distinguished road
Re: Network Tables

So, maybe I didn't follow your analysis and notes well enough, but FYI I had similar problems using direct python opencv VideoCapture bindings, until I had the Windows PATH variables set correctly to the OpenCV install. I'm seeing latencies like a second, but nothing like 30.
  #26   Spotlight this post!  
Unread 02-04-2014, 14:08
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Network Tables

Why wait until Auton or Teleop functions are called?

Why don't you just run your code all the time, and then additionally run auton or teleop code based on the driver station data?
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
  #27   Spotlight this post!  
Unread 02-04-2014, 15:40
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: Network Tables

Quote:
Originally Posted by apalrd View Post
Why wait until Auton or Teleop functions are called?

Why don't you just run your code all the time, and then additionally run auton or teleop code based on the driver station data?
I take it you are talking about the idea of waiting for auton and telop to start listening. Network tables does like what you say "run your code all the time" so that any c++ programmer can use it without having to know anything about writing a new thread (i.e. task). I agree that this is the best way because it can still work while robot is disabled, and handles 2 way communication.

But let's go back for a moment... when I first did UDP and waited for Auton and Teleop before I knew about this bug. Why did I do it then? Because writing threads is a messy business, and should be avoided if at all possible. I mean look at the trouble that happened with the lockup bug in Network Tables... Using winsock2 I was able to listen to packets on the same thread and it was nice and clean code to work out. So given that... all of our code runs on a single thread... we don't use the PID that comes with WPI... it does not need to be on a separate thread. Instead we introduce a time-slice delta in seconds to the computations... this way the PID can work in 10ms (ish) iterations on the same thead rather than the default 50 on a separate thread... thus being free from any mess of critical sections!
  #28   Spotlight this post!  
Unread 02-04-2014, 18:53
lucas.alvarez96's Avatar
lucas.alvarez96 lucas.alvarez96 is offline
Registered User
AKA: Lucas Alvarez
FRC #2576 (Chilean Heart)
 
Join Date: Dec 2013
Rookie Year: 2013
Location: Chile
Posts: 123
lucas.alvarez96 is a name known to alllucas.alvarez96 is a name known to alllucas.alvarez96 is a name known to alllucas.alvarez96 is a name known to alllucas.alvarez96 is a name known to alllucas.alvarez96 is a name known to all
Re: Network Tables

Thanks for all the help
So does anybody have the Network Tables library for C++?
I haven't got Wind River and nobody on my team know where the CD is...
__________________
FRC 2576 2015-2016: Mentor
FRC 2576 2013-2015: Programmer & Chairman's Presenter

Los Angeles Regional 2014: Regional Chairman's Award
  #29   Spotlight this post!  
Unread 02-04-2014, 19:37
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Network Tables

We run everything in a single task (including a UDP listener and RS232 listener). We just don't stop the task when auton or teleop is disabled. We clear the integrators and reset to a safe state when the disabled signal goes from low to high, and run everything in a single 10ms high priority task. The UDP listener reads in a While loop with a 0ms timeout and breaks when the read returns a timeout. The RS232 listener does similar.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
  #30   Spotlight this post!  
Unread 02-04-2014, 21:52
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

I don't have the UDP the setup down, but I would like to get the code down sometime soon.
I was wondering if anyone knows how to write a socket server with javax.microedition.io.*;
I am currently shot in the dark and have no idea to start
Closed Thread


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:42.

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