publish video on Kangaroo with Grip

[ahartnet]

Has anyone been able to publish video with Grip running on a Kangaroo? We were able to successfully connect the Kangaroo as a coprocessor (setting the network tables server address as 10.XX.XX.51), with the USB camera (microsoft lifecam) plugged into the Kangaroo - but we were then no longer able to get video on the smart dashboard.

[1024Programming]

This is kind of off topic, but, have you guys figured out a way for grip to run on startup for the kangaroo. We know GRIP will start, but will not open a grip project file(because they have not added parameters for opening grip saves)

[ahartnet]

No.. Right now I'm contemplating having a small monitor, keyboard, and mouse on the cart to turn grip on and off. It sucks down battery pretty quickly from what we've seen.

[ThomasClark]

The built-in webcam viewer in SmartDashboard is hardcoded to only connect to the roboRIO. If you use the GRIP SmartDashboard extension, you can customize the address to the Kangaroo PC.

The ability to run GRIP at startup depends on being able to give it command line arguments for what file to open. This was added recently (#498), and will be in the next release (which hopefully will be out before stop build day)

Another bleeding-edge feature is the ability to start and stop GRIP with NetworkTables (#505). This will probably help with battery usage.

NetworkTable table = NetworkTable.getTable("GRIP");

table.putBoolean("run", false); // Stop GRIP without killing the process

doSomeStuffThatDoesntNeedVision();

table.putBoolean("run", true); // Start GRIP again

[ahartnet]

Some dreams do come. I was just wondering if I could try to write a script that would get something from the network tables to turn grip off after autonomous - in case we decided to just manually aim after autonomous.

Thanks for your work

[s-taylor]

FYI, with the latest 1.3rc1 I have successfully gotten a kangaroo to boot, automatically start GRIP in headless mode, and stream USB camera data to the RIO's networktables for consumption by the robot.

[1024Programming]

Originally Posted by s-taylor

FYI, with the latest 1.3rc1 I have successfully gotten a kangaroo to boot, automatically start GRIP in headless mode, and stream USB camera data to the RIO's networktables for consumption by the robot.

Can you document your process and post all code because we and a lot of other teams desperately need guidance.

[ThomasClark]

Originally Posted by 1024Programming

Can you document your process and post all code because we and a lot of other teams desperately need guidance.

What part in particular do you need guidance on? There's already documentation on the wiki, but if you post any specific trouble I bet someone knows a solution.

[1024Programming]

Originally Posted by ThomasClark

What part in particular do you need guidance on? There's already documentation on the wiki, but if you post any specific trouble I bet someone knows a solution.

What we need to do is to publish the contours report from grip running on a kangaroo. We want the kangaroo to run our grip program on startup. We want to have a USB camera plugged in directly to the kangaroo. We want the kangaroo to have its own network tables and the roborio to take values from the kangaroo's tables and use those values in the code. We want to do this because we are under the impression that constantly publishing values to the roborio's network tables will slow down the roborio's processes. What we want is clear and easy to follow steps going through the entire process.

[ThomasClark]

Originally Posted by 1024Programming

What we need to do is to publish the contours report from grip running on a kangaroo.

This can be done with the "Publish Contours" operation in GRIP, with the networktables server address set to your roboRIO's address.

Originally Posted by 1024Programming

We want the kangaroo to run our grip program on startup.

I'm not exactly sure how to do startup programs on Windows, but I think there's a "startup" folder that you can just put things into. So, I think you could have a GRIP.bat file with something like:

C:\Users\MyName\AppData\GRIP\GRIP C:\Users\MyName\Documents\myproject.grip

Originally Posted by 1024Programming

We want the kangaroo to have its own network tables and the roborio to take values from the kangaroo's tables and use those values in the code. We want to do this because we are under the impression that constantly publishing values to the roborio's network tables will slow down the roborio's processes.

NetworkTables doesn't support federated servers AFAIK, and I'm not sure where you get this impression. You should be fine just using the roboRIO as the server.

[s-taylor]

I'm currently at the airport waiting to fly from Boston to San Francisco. Wireless is completely broken here so I won't be able to upload any documentation until late tonight. Iphone is not sufficient to do that!

That being said, we do have grip write straight to the roborio networktable and were not overwhelming memory or cpu. And we used the startup folder-- i added a shortcut to grip there and modified the shortcut properties to add the commandline args for the grip file as well as --headless.

One more important note: Using the USB to connect the Kangaroo to the RIO does not work for me-- something happens that terminates the network connection after a minute or two, and GRIP never is able to reconnect. It's not grip though-- looking in windows the network connection itself has disappeared. I did not get enough time to debug why the network connection failed in the first place.

I was able to get everything running consistently this morning by using a usb-to-ethernet dongle and going into the radio. That connection was stable and I was getting good and consistent results.

More details later.

[s-taylor]

Rather than type everything into a posting window, I created a Word doc to hold the whole write-up.

The document (hopefully) captures everything we did to get Grip + Kangaroo + USB Camera + RoboRio + Robot Code working (in Java).

My email is also in the document so if you have questions/clarifications feel free to contact me.

Hope this proves helpful to folks...

[1024Programming]

Originally Posted by s-taylor

Rather than type everything into a posting window, I created a Word doc to hold the whole write-up.

The document (hopefully) captures everything we did to get Grip + Kangaroo + USB Camera + RoboRio + Robot Code working (in Java).

My email is also in the document so if you have questions/clarifications feel free to contact me.

Hope this proves helpful to folks...

Thank you so much for doing this, this guide has been really helpful and will help so many teams!

[1024Programming]

Originally Posted by s-taylor

Rather than type everything into a posting window, I created a Word doc to hold the whole write-up.

The document (hopefully) captures everything we did to get Grip + Kangaroo + USB Camera + RoboRio + Robot Code working (in Java).

My email is also in the document so if you have questions/clarifications feel free to contact me.

Hope this proves helpful to folks...

One other question though...We know we can replace the system.out() prints with Driverstation.reporterror() or some other smartdashboard visual...BUT where does the system.out print to? I know that when I programmed outside of robotics, the System.out would print to the compilation window. That would be in eclipse in robotics...but is eclipse really connected to the robot after code deploys? If not, where do I find those prints?

[s-taylor]

System.out will go to the console.
There is a view you can add in Eclipse that will display the RoboRio console in the same frame area that the compilation logs show up. In eclipse, it's window->show view -> other... -> Riolog. Works great, as long as the compilation laptop is connected to the robot. I have found that sometimes the connection is broken and re-deploying the program to the robot gets the console connection back.

"New for 2016" they also shunt the system.out to the DriverStation console window for you... but I have determined over time that not all messages actually end up there-- it seems that if there is enough output flowing in, it gets overwhelmed and drops messages. Thus, if you are printing a value every command iteration (20ms) don't expect to see everything show up cleanly on the DS. It works for the most part for occasional messages (like invoking a command, or reporting an error condition).