Quote:
Originally Posted by whcirobotics
You can see that the CPU starts giving error messages such as “loops running slow” at the same time as lost packets occur. These errors occur even when we are doing nothing on the controls. The robot is just turned on and enabled.
I wonder if there is something we have done wrong or is it something else?
|
Quote:
Originally Posted by flameout
Perhaps this was it -- I recall errors flowing by, and they weren't triggered by any of our code.
I did not realize that the code would repeatedly throw errors if no camera was present -- during the build season, I'll have to try removing that code and see if it improves.
|
If you look inside Begin.vi, the camera code is there for you to look at, and could account for the lost packets you guys are receiving.
Quote:
Originally Posted by flameout
reading a single Analog channel at 100 Hz (granted, this was output to a front panel, but no other processing was performed) maxed out the processor and prevented code from deploying (due to starvation).
|
You're sampling the analog input at 100 hz, that means that you're sampling the signal 100 times per second. Some quick math indicates (1000 ms = 1 second, 1000 ms / 100 NumOfCycles = 10 ms) that you only need to read the signal in the code once every 10 ms. This can starve whichever thread (and slow down the loop) the getSignal function is in, and can be particularly inefficient. I think this may be your real problem, since whcirobotics would have the same camera problem but exceedingly low processor utilization (~12.5%)(also, note that his problem was a large number of dropped packets).
Navigate to Robot Main.vi, and look for something called Timed Tasks.vi near the bottom of the 'screen' (just below the Driver Station StartCOM vi and Vision vi. You'll see two loops -- one that runs every 10 ms and one that runs every 100 ms, and some accompanying joystick code. Essentially, replicate the joystick code but have the action you want performed inside the 10 millisecond loop. This has the added benefit of running independently from whichever mode the robot is in*, which can be handy.
*Note that you should just get the value of whatever signal the sensor is reading there, and then pass that on to <Autonomous/Teleop/Whatever> via Global Variable or however you want to handle it.