What Did you use for Vision Tracking?

[aeastet]

Team 107 was using the NI Vision software and IP or USB camera. The vision software was located on the driver station. This has limits for bandwidth from the field but running smaller pictures and some compression we were able to push these limits.

They also had a on board Kangaroo computer running NI Vision and using the network tables to communicates. Doing this will allow for faster video processing in the future if we write our own camera drivers or see what is out there. It also allows for bigger pictures so we get more resolution and accuracy. Doing this would also allow for a second camera to be used going through the driver station so the drivers could see where they were going without taking up targeting bandwidth.

Both solutions were capable of running 30fps so for weight reason they went with the desktop version of the software. It is fun to play with the kangaroo and a target.

[Joe Ross]

We used the LabVIEW vision example, integrated into our dashboard. I took a quick look at the teams calibrating their vision on the Einstein Mass field, and over half of them used LabVIEW or the NI Vision assistant.

[s5511]

Did using the Labview Vision example running on the roboRIO result in a significant performance decrease?
Did robot controls become more sluggish or have more lag because of the extra CPU usage of the Labview Vision Processing?

[alebcay]

We began the season with GRIP running on the roboRIO for an IP camera. For some reason, it would never work on the official field FMSes (it worked fine in our shop and on the practice fields).

We decided to throw all of that out the window and we eventually rolled a Python script utilizing OpenCV on a Raspberry Pi 3 with an accompanying camera module. The Pi communicated with the roboRIO through a USB to Ethernet cable (Ethernet went into the Pi, USB went into the roboRIO's USB Host port), thus creating a separate network between the RIO and the Pi. Finally, we used NetworkTables to actually transport data on the connection. We hoped to avoid any sort of meddling that the FMS might cause by creating our own direct connection between the RIO and Pi (bypassing the radio altogether), and this seemed to do the trick for us.

[tomy]

Originally Posted by alebcay

We began the season with GRIP running on the roboRIO for an IP camera. For some reason, it would never work on the official field FMSes (it worked fine in our shop and on the practice fields).

We decided to throw all of that out the window and we eventually rolled a Python script utilizing OpenCV on a Raspberry Pi 3 with an accompanying camera module. The Pi communicated with the roboRIO through a USB to Ethernet cable (Ethernet went into the Pi, USB went into the roboRIO's USB Host port), thus creating a separate network between the RIO and the Pi. Finally, we used NetworkTables to actually transport data on the connection. We hoped to avoid any sort of meddling that the FMS might cause by creating our own direct connection between the RIO and Pi (bypassing the radio altogether), and this seemed to do the trick for us.

That's an interesting idea. How did you get the values over the serial connection?

[TomLockwood]

You reference "The latency correction discussed in the presentation at worlds" - is that presentation available?

Thanks,

Originally Posted by slibert

***

The latency correction discussed in the presentation at worlds is a great idea. We have a plan for that....

[alst]

Assuming you mean this one, there's a mostly-complete recording of it here. There may be a better recording posted in the future, but I haven't seen it yet if it has been.

[thatprogrammer]

Here's an interesting question... did any teams run live tracking like 254? In other words, were any other teams able to get their turrets to track the goal as they drove towards it, dynamically following it?

[cprofitt]

We ended up using openCV on a RasPi 2 then used Network Tables to transmit the data to the RoboRio.