Grip running out of memory

[Ken P.]

Does the RoboRio system restart GRIP when the robot restart command is sent? Another mentor and I were wondering if the restart command would free the resources in use by GRIP or if you then have 2 sessions running at once.

[ThomasClark]

Originally Posted by Ken P.

Does the RoboRio system restart GRIP when the robot restart command is sent? Another mentor and I were wondering if the restart command would free the resources in use by GRIP or if you then have 2 sessions running at once.

Restarting the robot should kill all instances of GRIP. It'll start back up again if you deploy or if your robot program automatically starts GRIP.

Also, as a general response to this thread, I've found that some extra JVM options (-Xmx50m -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError) help with OOM errors. The next release (v1.2.0) will have these by default, and allowing custom JVM arguments when deploying.

[1024Programming]

Originally Posted by ThomasClark

Restarting the robot should kill all instances of GRIP. It'll start back up again if you deploy or if your robot program automatically starts GRIP.

Also, as a general response to this thread, I've found that some extra JVM options (-Xmx50m -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError) help with OOM errors. The next release (v1.2.0) will have these by default, and allowing custom JVM arguments when deploying.

How do I make the robot automatically start GRIP from the robot code?

[Greg McKaskle]

In one of these situations where you are running out of memory, can someone shell in and run top to see what memory is being used by various processes. I don't really expect that this is because of the LabVIEW runtime, but the numbers will tell the tale.

Greg McKaskle

[jmguillemette]

we are running into the same issue.

some observations:

This only started happening to us after we applied GRIP 1.1.1 when we were on grip 1.0.0 everything was mostly working (no mem issues what so ever)

if tossing this onto a Pi is the answer then i think some guidance on how to set that up will be needed.

thanks
j.

[xjschwen]

Originally Posted by jmguillemette

we are running into the same issue.

some observations:

This only started happening to us after we applied GRIP 1.1.1 when we were on grip 1.0.0 everything was mostly working (no mem issues what so ever)

if tossing this onto a Pi is the answer then i think some guidance on how to set that up will be needed.

thanks
j.

Here is the first stop for GRIP on RPi2
https://github.com/WPIRoboticsProjec...Raspberry-Pi-2


I spent yesterday making GRIP run on Linux Mint 17.3 so that I could play with it off-line before getting it running on the PI which I should start with later this week with the team.

I have also learned alot from this site as well. He specializes on open-cv on Pi.
http://www.pyimagesearch.com/

[brk]

Originally Posted by ThomasClark

Restarting the robot should kill all instances of GRIP. It'll start back up again if you deploy or if your robot program automatically starts GRIP.

Also, as a general response to this thread, I've found that some extra JVM options (-Xmx50m -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError) help with OOM errors. The next release (v1.2.0) will have these by default, and allowing custom JVM arguments when deploying.

I'm running v1.2 already, so does it have these options already? I was going to change the launch code to try to tweak the memory, but if that's been done already in v1.2 it wouldn't be worth it. I see the GRIP jvm is consuming about 185-190M of the 256M of RAM. The Robot & Network programs are the next highest consumers totaling about 50-55M, so its definitely GRIP chewing up all the RAM. We've used the Beaglebone Black in the past for image processing, but really wanted to try keeping it simple and use the rio. Is there a chance v1.3 is coming out soon and addresses the memory issue?