Grip running out of memory

[SLAB-Mr.Thomas]

We don't use Java on our team. Had to install JRE on roboRIO just for GRIP - our first experience with Java there.

I copied the GRIP C++ example but one line had to be changed to prevent instant crash - the line declaring the NetworkTable variable "grip" has to be in the class. Otherwise, I think the example worked well enough.

The rest of my changes to the example were to help debug the various error messages that seem to come and go.

I wonder if the WPI GRIP team is monitoring these posts. I've mentioned 2 errors I haven't seen posted elsewhere. Those random occasional out of memory are a real pain and could be a deal breaker for us using GRIP and I really want to use it. Incorrect labeling of report variables needs attention, too.

Other errors I've gotten have been mentioned elsewhere, I think.

[ThomasClark]

Originally Posted by SLAB-Mr.Thomas

I wonder if the WPI GRIP team is monitoring these posts. I've mentioned 2 errors I haven't seen posted elsewhere. Those random occasional out of memory are a real pain and could be a deal breaker for us using GRIP and I really want to use it. Incorrect labeling of report variables needs attention, too.

Other errors I've gotten have been mentioned elsewhere, I think.

I really recommend running GRIP on a coprocessor if you're running out of memory a lot. The roboRIO only has 256 MB of RAM, and most of it's taken up the LabVIEW runtime and your robot program. The Kangaroo PC is a really good option, although people have also gotten GRIP to run on a Raspberry Pi.

Can you describe the incorrect labeling problem? I do monitor Chief Delphi for GRIP-related stuff, but you'll get a faster response if you open an issue.

[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?

[medofbr]

Originally Posted by ThomasClark

I really recommend running GRIP on a coprocessor if you're running out of memory a lot. The roboRIO only has 256 MB of RAM, and most of it's taken up the LabVIEW runtime and your robot program. The Kangaroo PC is a really good option, although people have also gotten GRIP to run on a Raspberry Pi.

Can you describe the incorrect labeling problem? I do monitor Chief Delphi for GRIP-related stuff, but you'll get a faster response if you open an issue.

We are running into the out of memory problems and are considering using the Kangaroo PC or Raspberry Pi. Can others comment on what levels of success they have had with either of these two approaches?

Some of the people were talking about this on Gitter.im. In order to prevent the entire JVM from crashing you may need to only allow "-Xmx50M" as the runtime arguments while deploying GRIP. GRIP does also prefer to have ~90MB of RAM if it's available. Otherwise, you can always work with what you have (adjusting the RAM by 1MB until it stops crashing). "-Xmx50M" -> "-Xmx55M" -> ... -> "-Xmx128M"

There is a confirmed system with a raspberry pi 2, but sometimes the system claims to be running at ~200% CPU usage. It's better off to ignore what the Pi thinks and simply test the functionality when it comes to the raspberry pi 2.

Good luck! Feel free to stop by the gitter.im chat if you have any more questions about GRIP.