Worried about high CPU usage in CRIO - Chief Delphi

[Ryan Quellet]

http://www.chiefdelphi.com/forums/showthread.php?t=101437

Ryan Quellet

[Michael Chau]

Team Update from yesterday has prompted the issue that high CPU usage
of the cRIO is a big problem. The WPI Library itself has shown to
someone that it is very inefficient in Labview so we may have to try
and optimize the motor code as a fix.

http://www.chiefdelphi.com/forums/showpost.php?p=1143891&postcount=18

On Mar 13, 10:17 pm, Ryan Quellet <rquel...@gmail.com> wrote:
> http://www.chiefdelphi.com/forums/showthread.php?t=101437
>
> Ryan Quellet

[Michael Chau]

I have looked at the WPILibJ source code and could not really find
anything to optimize as of now.

My current ideas on things that we can do, some are probably what you
guys have already thought of?

Measure the approximate CPU % usage of each feature (manual elevator
axis, manual roller axis, elevator P control, camera tracking etc.)

Test code currently in continuous instead in periodic to see how the
robot reacts (All the manual controls definitely.)

Use less function calls. Instead of getting the elevator's encoder
count multiple times within a loop it will be called once and set to a
variable. It is a lot less costly to reference a number in memory than
to run a process to retrieve the number from the encoder. This I
probably will do tonight since its a simple change.

RAM usage I believe we have checked to be fine since there was at
least 8 Megabytes free?

There is not optimization but we can spend a little time on getting
the SendableChooser to work as an autonomous timer delay selector. I
just have to figure out what does it send back to the cRIO, and there
is source code in java as an example. The analog dial will definitely
be the main autonomous mode selector (do nothing, shoot baskets from
current height (Gull Lake,) or lift elevator and shoot baskets etc.)

I will also attempt to revise the position and names of constants and
code to a more logical, standard, and readable state. There is also
apparently a robot preference file class that I have somehow passed
over in the WPILib notes that we can test out if we have time and
everything is working.

We will definitely calibrate our camera on the actual competition
field when we come on Thursday. We will get the camera stream working
on the SmartDashboard again, I had it working in like week 4 or 5. We
should debug limit switches and encoders to make sure all set points
are correct and that they are working fine. The revised bridge
manipulator probably will be tested on the practice field as well.

Also, curiously enough teams are saying that they are just using the
camera as a second pair of eyes and are doing well with it. I assume
that the autotracking was never tuned enough to compete with the
experience gained by drivers with manual control.

[Michael Chau]

Now that I have clearly looked, the SendableChooser only works with
the Command Based Robot Base not the Iterative Robot Base. Another
method open is having the SmartDashboard edit preferences stored on
the cRIO. I am looking into how to use the preferences class now.

[Michael Chau]

The preferences appears to be a class to interface like a CSV but does not allow direct manipulation for some reason. The SmartDashboard can edit these preferences. This probably will be used to time in the shots, and we will need to acknowledge a minimum amount of time between the shots so the times aren't too close.