2019 FRC camera streaming system low latency and bandwith

#1

just showing the system i have created that streams low latency and bandwidth
also running with port,bandwith limits

#2

Cool! What camera? What image size? What frame rate? What bandwidth?

#3

Microsoft lifecam, 480p , 30 frames/sec , 180 - 210 kb bandwith

#4

480p = 0.2 - 0.3 sec delay
can even go up to 720p and have 300kb/sec
but not needed as it raises the latency to 0.46 sec

#5

For static image (images that don’t change) you will get low latency.
What happens to the latency if there is alot of movement and activity or the robot is moving?

#6

No actually latency stays the same all the time
Just the bandwidth goes down when there is not alot of pixels changing color all the time
( meaning movement )
So the max bandwith is 300 kb/sec
Less movement means less data transfer

#7

I hate to say it, but our driver found that kind of latency very hard to drive with last year. That is honestly kind of high. With the WPILib CSCore server running on a coprocessor, we can get latencies around 150ms. But yes, the images are smaller in my tests.

Also, measuring latency is not easy. You might want to see how we did it, getting real numbers:

Good luck.

#8

i measured it correctly dont worry…
also if the driver can not drive with that latency then he shouldn’t be a driver
just saying as i am the driver of my team ¯_(ツ)_/¯

Best Regards
Shadi Shakkour #7079

#9

I’m gonna have to disagree with you. Accusing someone of being “not good enough” if they can’t work with inadequate technology is the kind of thing I try to avoid doing. Someone isn’t a bad truck driver if they can’t drive a semi-truck with a broken clutch in the same way an FRC driver isn’t capable of driving at their peak performance with a highly delayed camera stream. Dragging others down and handing out insults to defend your own creation really isn’t a great thing to do. Besides, there are always ways to make your camera server faster. How do we decrease latency? Send less bits. Try using JPG to compress the image and then send that as a base64 string. I’ve had great success with that method

1 Like
#10

I sense there may be a language and/or cultural gap here, so let’s be careful we don’t get too bent out of shape before confirming any malice was intended.

Shadi, here’s how I think about it: The goal is to have the robot perform as well as possible. This means having a driver who can operate it well. Tools like cameras help an operator do their job better. If the combination of you as driver plus your stream solution causes your robot to be the best it can, it is the correct answer for your team.

Others have alternate experiences. Our drivers last year could not tolerate a 300ms delay and therefor did not use the cameras we provided. Still, they were the most talented folks on our team, we did not have any other people to go with. Therefor we redesigned our camera solution this year to reduce latency.

Tools should help you toward your goal. A tool should never dictate what the goal is.

2 Likes
#11

What codec?

#12

i never intended to make anyone upset i meant it in a good way ( as in the drivers could do better )
and so i say sorry to @Maxcr1 and @gerthworm and to everyone else that got insulted.

Best of regards
Shadi Shakkour #7079

1 Like
#13

No problem at all, and no harm is done :).

I am interested, got any details on the setup? Are you using a custom protocol for streaming pixels? No worries if you want to wait until after the season to share :slight_smile:

#14

i am not one of those … :sweat_smile::grin: ( no harm intended with this comment )

i will share more tomorrow as the time now is 00:00 and i have a math exam tomorrow
( god i hate it ( the teacher doesnt know how to teach correctly :joy: ) ) xD

btw from what team are you and if u have any social media

#15

Yes - go to bed and best of luck tomorrow! Team 1736 Robot Casserole from Peoria IL USA! youtube twitter facebook instagram github

1 Like