Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent color sensor calls when not needed. #95

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ErikCald
Copy link
Contributor

This small change means the color sensor will only be called when the code asks instead of always.
The code happens to always call the color sensor UNLESS the switch closest to the shooter is pressed.
Hopefully this break in color sensor calls can fix the issue described below.

In match 105 at DCMP, ColorSensorSubsystem.periodic() was reported at taking 0.35s.

Here is my detailed notes on what I found reading the driverstation logs:

Loop overrun message, displays time of each subsystem/command:
Match 68 -> All ColorSensorSubsystem.periodic were below 0.0025s
Match 95 -> All ColorSensorSubsystem.periodic were below 0.0025s
Match 105 Auto Period -> All ColorSensorSubsystem.periodic were below 0.0025s
Match 105 Tele Period -> ALL ColorSensorSubsystem.periodic were ABOVE 0.35s

The moment teleoperated started, ColorSensorSubsystem.periodic() was taking way too long to run.
Motor safety was saying "hey, I haven't gotten a new percent output for the drivetrain motors in awhile I'm going to stop the motors from moving." (I believe it is likely that motor safety was causing the lapses in control. Likely being the key word, I can not confirm it since we seem to always get motor safety messages)

Battery Voltage reported from the driver station, voltage was a flat line for over 20 seconds :
Beginning of the match = 12.7 V
End of the match = 12.3 V

Number of reported brownouts = 7
Match 105 has the lowest number of recorded brownouts. (Match 105 = 7 brownouts, match 98 = 9 brownouts, match 25 = 10 brownouts, all other matches were >21 brownouts, match 68 has the highest number with 71 brownouts)

This small change means the color sensor will only be called when the code asks instead of always.

The code happens to always call the color sensor UNLESS the switch closest to the shooter is pressed.

Hopefully this break in color sensor calls can fix the issue.

In match 105 at DCMP, ColorSensorSubsystem.periodic was reported at taking 0.35s.

Here is my detailed notes on what I found reading the driverstation logs:

Loop overrun message, displays time of each subsystem/command:
Match 68 -> All ColorSensorSubsystem.periodic were below 0.0025s
Match 95 -> All ColorSensorSubsystem.periodic were below 0.0025s
Match 105 Auto Period -> All ColorSensorSubsystem.periodic were below 0.0025s
Match 105 Tele Period -> ALL ColorSensorSubsystem.periodic were ABOVE 0.35s
The moment teleoperated started, ColorSensorSubsystem.periodic() was taking way too long to run.
Motor safety was saying "hey, I haven't gotten a new percent output for the drivetrain motors in awhile I'm going to stop the motors from moving."

Battery Voltage reported from the driver station, voltage was a flat line for over 20 seconds :
Beginning of the match = 12.7 V
End of the match = 12.3 V
Number of reported brownouts = 7
@ErikCald
Copy link
Contributor Author

I also just discovered that the RoboRIO CPU% stays below 50% pretty much all the time, but in match 105 it jumps from around 45% to 75% and stays at 75% for the rest of the match (75% continues until killswitch). This sudden jump happened exactly when the robot started to malfunction. See the images below, the red line is the RoboRIO CPU% and the yellow line is the voltage (notice match 105 has a normal battery voltage and is greater than 12V to start and at the end too.)

Match68:
DSLogs_2022DCMP_Match68

Match98:
DSLogs_2022DCMP_Match98

BAD MATCH ->Match105:
DSLogs_2022DCMP_Match105

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant