|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
GRIP Co-processor bandwidth usage
Our team has been looking into using a co-processor attached directly to our robot to run GRIP, but we had a question concerning how the information traveled along the network: When a co-processor is wired to the robot, do the video feeds and network tables stay on the bot, or are they also sent to the Driver Station?
|
|
#2
|
||||
|
||||
|
Re: GRIP Co-processor bandwidth usage
It does if you send them over... I'm afraid I don't understand the question.
If you have a camera feed on the dashboard than you will consume bandwidth equal to what the fms will tell you. If there's nothing in the dashboard than it won't consume bandwidth |
|
#3
|
||||
|
||||
|
Re: GRIP Co-processor bandwidth usage
We're looking at using GRIP on a co-processor, headless since we can't publish the feed to the DS (due to DS restrictions), we wanted to make sure that the video wasn't leaving the bot. It's how I believed it would work, but another mentor had some concerns. Just didn't want to rely on what I thought.
|
|
#4
|
||||
|
||||
|
Re: GRIP Co-processor bandwidth usage
Quote:
|
|
#5
|
|||
|
|||
|
Re: GRIP Co-processor bandwidth usage
It sounds like op is asking if sending information from their co-processor will take up bandwidth to the same extent sending your video stream to the driver station would. We all know that sending a live camera feed back to the driver station has the possibility to put you over the bandwidth limit. However I believe the main appeal of using the co-processor for vision on the robot itself is that it won't eat up your bandwidth.
The 7mb/s limit is from the radio on the robot to the driverstation. Not local co-processor to radio to local roborio. Please correct me it I'm wrong though. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|