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.
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)
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.
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](https://github.com/WPIRoboticsProjects/GRIP/pull/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](https://github.com/WPIRoboticsProjects/GRIP/pull/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
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
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.
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.
This can be done with the “Publish Contours” operation in GRIP, with the networktables server address set to your roboRIO’s address.
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
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.
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.
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…
Grip plus Kangaroo.docx (29.6 KB)
Grip plus Kangaroo.docx (29.6 KB)
Thank you so much for doing this, this guide has been really helpful and will help so many teams!
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?
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).
Great job Scott for the detailed explanations and thank you very much sharing!
s-taylor, your doc was very helpful to our team this year in getting our GRIP and Kangaroo to work.
“It might be possible to VNC in from another computer already on the robot radio wireless network, but we never got around to trying that. Hmmm…”
We were able to do this, but we had to set the Kangaroo to a static IP on the network.
We were wondering if there was any way to get the GRIP image that we published to show up on the SmartDashboard. It seems that the GRIP output viewer requires that you have a solid frame rate, yet the frame rate on the GRIP is nowhere near solid (fluctuates from 20 to 30). The image only shows up when the frame rate from GRIP and the smartdashboard are the same.
We never pursued the final use of the GRIP SmartDashboard extension that ThomasClark posted earlier in this thread.
Our driver decided in the end that looking down at a live video feed was more distracting than maintaining continuous focus on the playing field, so we never finished that aspect of the system.
However, if you are seeing issues with the use of that extension, I’d contact Thomas and see if it’s a configuration issue or an “architectural” divot that could be addressed. Definitely re-post if you find any workarounds, and I’ll add that to my document!
Our team found the input from the camera to be very useful for driving, especially when we were behind defense like the drawbridge, picking up a ball or lining up for a cheval run.
Our solution for the competition was to have 2 cameras, one on the kangaroo and vision filters, and one on the RIO that displayed on the driver-station.
Oh, I personally agree with you, and your suggestion is exactly what I would do if I was the driver. But I’m not. 
Sometimes, you just have to let the students do what they think is in their best interest and let them loose on the field…