GRIP on RIO

[axton900]

I have been experiencing memory issues when I try to run GRIP on the rio. The RIO reports that the JRE can not allocate enough ram for the JRE to run.
Has anyone else been experiencing this and found a fix?
Thanks!

[ThomasClark]

This is probably either because:

• Multiple instances of GRIP are running (either from multiple deployments, or from your robot program starting GRIP)
• GRIP is not garbage collecting at an appropriate rate, so it's actually running out of memory

Both of these were fixed in v1.2.0, which was released today. Let me know if it works now.

[MaikeruKonare]

I suggest NOT running Grip on your RoboRio.

We have been experimenting with Grip for weeks and with a fairly standard pipeline, Grip pulls over 80% of the RoboRio's processing. (Unless there is some kind of memory leak error. Grip is an unfinished product.)

If you're dead set on using Grip, run Grip on your PC and have the robot send you images over the network. After doing processing, send the network table information about the processed image back to the robot.

Good luck!

(If you give up on Grip, try RoboRealm! Works great!)

[ThomasClark]

GRIP running on an onboard coprocessor like the Kangaroo PC is probably the ideal setup.

[MaikeruKonare]

Originally Posted by ThomasClark

GRIP running on an onboard coprocessor like the Kangaroo PC is probably the ideal setup.

Yeah! One of our mentors had that idea; we actually ordered a Kangaroo a few days ago. Grip does its job amazingly it just needs space to do that job!

[kylelanman]

When we attempted to run GRIP with an HSV filter, find contours, and filter contours we found GRIP was taking up just over 50%. With that we decided to use the information available in the GRIP wiki and the source code to port our working GRIP implementation to OpenCV C++ and run it directly in our robot code. We decided GRIP is a great tool for rapid prototyping vision algorithms but deploying it as is has major drawbacks. Other than being a CPU hog there is no way to pause it or control the frame rate. For our specific application we just need to grab a single frame and process it maybe 10 times the entire match. We are okay with having high CPU for a short period of time but the only way we could figure out how to do this with GRIP was to kill the process and restart it when we weren't using it and that seemed like a hack.