Roborio CPU what is resonable

[cpapplefamily]

We been digging into why it appears that our Roborio CPU utilization seems high. Disabled and Teleop seem to run at 80-90%. Its tough to tell by simply watching the graph but it trends nearly on top of the voltage plot. When we deploy new code it drops to 40-50% as it relaunches then back to 80-90%.

We are running the command based program, Vision is processed on a co-possessor (Kangaroo), Camera is an IP Axis webcam. The Roborio has been recently re-imaged to try and assure no old on Roborio GRIP stuff is still there. We have removed most of our SmartDashboard.put_______ code from the program

Last night we tried a new program written from scratch using Robotbuilder that simply had one Subsystem (Drive train), one command (DriveRobot), and one Joystick. Drive Train has 4 talons and 1 analog gyro to drive the Mecanums. No bells, no whistles. Simple get 3 Joystick analog values and Drive. Even with this the Roborio CPU was 50%.

What is reasonable CPU usage?

[euhlmann]

Looking at some old logs still on my computer from build season, it looks like 50-70% is "reasonable". The Rio is not all that powerful...

[Thad House]

So a robot program with nothing running causes about 30% cpu usage by default. This is inherent to the driver station thread, and slow IPC calls on arm linux, which are used to get the driver station values and joysticks. We are currently working on some fixes for this, but for the 2017 season the slow calls all happen on a separate thread, so other threads should be free to do as they please.

I would have to see your code, but depending on how the joystick code is written, and some other things, it is really easy for code usage to get out of hand really quick. One of the big things currently is a call to any of the Driver Station status checks (IsOperatorControl(), IsAutonomous() etc..) or accessing any joystick properties other then axes, povs or buttons will be a fairly slow call (relatively, 100-200us vs the expected 1us or so) and can cause the RoboRIO to show excess CPU usage when in reality it is probably OK.

[AustinSchuh]

Looking at some old logs still on my computer from build season, it looks like 50-70% is "reasonable". The Rio is not all that powerful...

That made me laugh. Back when I was a student, we were excited about a 10 MHz Microchip processor that you could program in C (instead of Basic), and it was pretty fast. Now I'm dating myself...

The roboRIO is actually very fast. It is a dual core A15 clocked about 1 ghz with a FPGA attached to it and 256 MB of ram. That's a serious amount of CPU power. An A15 is also an out of order processor, and (if I'm reading right), triple issue, and has vectorized floating point math. That means that it can execute 3 instructions in parallel per core, and will re-order instructions to be more efficient. It's not quite as fast as a brand new cell-phone processor, but it's actually pretty close.


The challenge, as Thad aptly put it, is that it takes about 50% of the CPU to interact with the services running on the roboRIO to talk to the field and the CAN bus. That's before you write a line of code. There are also certain calls which use a bunch of CPU. Setting solenoids is one of them. Reading joystick values/DS values is another. If you are worried about CPU usage, you want to minimize those calls. You can benchmark the various calls to see how much CPU they use.

We run our roboRIO at about 80-90% CPU. About 50% of the CPU is taken up by code outside our control.

[cpapplefamily]

I've posted the code before here on CD. Here it is againhttps://github.com/GraniteCiyGearheads3244/FIRSTStronghold2016/tree/master/SirAntsABot_Summer admitted its an overburden to read. With some of this feed back we are building a fresh program slowly adding in the functions we really used and focusing on the CPU usage as we go to see if there is a point it get out of control. This is also to get a better understating to what might be happening.

Thanks for all the feed back and confirming 50% is the starting point.

[AustinSchuh]

I've posted the code before here on CD. Here it is againhttps://github.com/GraniteCiyGearheads3244/FIRSTStronghold2016/tree/master/SirAntsABot_Summer admitted its an overburden to read. With some of this feed back we are building a fresh program slowly adding in the functions we really used and focusing on the CPU usage as we go to see if there is a point it get out of control. This is also to get a better understating to what might be happening.

Thanks for all the feed back and confirming 50% is the starting point.

(As much as I'd love to read through your code and give advice, I'm not a strong Java programmer, and am too busy to really dig in and do it justice)

Admittedly, this is a very C++ targeted answer, but you can use strace to help understand which calls are triggering a RPC, and which calls are accessing the memory mapped IO of the FPGA. As you can probably imagine, the RPC is expensive, and the memory access is cheap. You can likely use strace with Java, but there could be more noise from other calls that Java makes.

I always struggle to get good benchmarking numbers, but the limited numbers that I got were from gperftools' sample based profiler. They showed that most of our execution time was associated with the RPC calls, and a good 60% of the time in the RPC calls was in the kernel.

[adciv]

We use LabView and typically have a decent amount of code running on our robot. According to the log viewer, our CPU usage was 55% when not enabled and 65-70% when enabled. This was with our vision processing code running on the RIO. I suspect the increase in tele was due to us having the "devref get" active in our teleop section of code when it really only needs to run once.

I'm not familiar with the FRC Java API, but I do have some questions for you based on what I can read.
1) How often are your PID loops running? (in ms or hz)
2) How often are you updating Smart Dashboard? (in ms or hz)

[cpapplefamily]

We use LabView and typically have a decent amount of code running on our robot. According to the log viewer, our CPU usage was 55% when not enabled and 65-70% when enabled. This was with our vision processing code running on the RIO. I suspect the increase in tele was due to us having the "devref get" active in our teleop section of code when it really only needs to run once.

I'm not familiar with the FRC Java API, but I do have some questions for you based on what I can read.
1) How often are your PID loops running? (in ms or hz)
2) How often are you updating Smart Dashboard? (in ms or hz)

I found two PID's set to .001 ms period. Changed to .002 made a difference. Shouldn't it be more like .02 ms? Maybe .01 ms?

How do we control Smart Dashboard updates?

[euhlmann]

SmartDashboard updates happen when you call the "set" methods on the SmartDashboard object. You can try calling them less often (instead of on every tick, try once every 2 or 3 ticks)

[cpapplefamily]

Is there a simple trick to pick the tick? Do we wrap the update dashboard variable condition and set the variable true every few program scans?

We have removed a lot of the none necessary dashboard data.

[Thad House]

By default, SmartDashboard only actually sends new data every 100ms. It stores the data locally in the table before that time. Yes too many updated keys can be a problem, but in all honestly 50+ keys isn't bad at all, and many teams run many more keys.

The PIDController set to 1 ms is definitely a problem. Unless you are using CAN, PWM motor controllers can only update every 5 ms. So running much faster then that isn't actually helping much. Plus unless your code loops can handle that speed, or you are running a shooter wheel, even 5 ms is too fast. We usually recommend between 10 and 20 ms, as there is usually plenty of CPU power to run that, and most mechanical and control systems can't handle much faster then that anyway.