We had a problem a few times where the drivetrain at least would be unresponsive going into teleop. I have done repeted testing tonight and have not been able to replicate the issue. There is nothing in disabledInit. I do not have the DS logs right now. I think the only evidence that I have of it happening is this match video .
Does anyone have an Idea here? Was it an FMS delay?
It’s not an FMS delay.
All the other robots are working fine.
When you tried to recreate the issue at home, did you use “Practice” mode on the Driver Station?
That replicates the proper match sequence of an event match.
I suspect your autonomous code is not giving up control at the end of the Auto period, but is delaying.
I was using Practice mode for all the tests.
There should be nothing holding the drivetrain as all commands get canceled in teleopInit().
To me, it looks like a smooth transition to teleop from auto as the robot does move at the beginning of teleop before stalling. Then I see a few seconds later in teleop the robot stalls again. I don’t know why the robot stalls - could be anything from a loose wire to Java garbage collection - but I don’t think it has anything to do with the auto command.
If you can grab the two DS log files (real files, not a screenshot) from that match we can take a look.
The DS logs are your best friend. They generally won’t show errors if it’s a code issue like a slowdown or blocking action, but dropped communications will show up.
I do not think I can get the log files anytime soon. That laptop is currently “in use for FTC”.
Sorry about that, I will see what can be done.
Understood. We’ll be here when you need us.
If something like this happens in a future event, ask for help diagnosing the problem from any CSA, the field, the LRI, other experienced teams.
There is a lot of help available, and something like this is usually pretty easy to diagnose on-site.
Okay, I know that we have the computer now, although I will not have access for a while.
When I do have time to look at this again, how would I go about figuring out which log file is the correct one? I know which day this happened, but have no idea about the time.
DS log files from matches are tagged with the event and match number in the ds log viewer
2023_10_07 12_30_19 Sat.zip (75.4 KB)
The Driver Station has finally returned from its “adventure with FTC”. I put the log and the events file in the zip.
I’m not sure if the code you posted above is what’s running in the logs you just provided, but there’s not too much useful in the logs. I did see ~5 seconds of repeated NavX resets, which is certainly odd, but I don’t see where that would’ve happened based on the code provided (so I assume there’s some differences).
That said, I did look through the code and spotted this line whichdefinitely isn’t going to do what you want: MAXSwerve-Rate-Limited/src/main/java/frc/robot/RobotContainer.java at main · Delmar-Robotics-Engineers-At-MADE/MAXSwerve-Rate-Limited · GitHub
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.