I’ve got a question about coding autonomous with java. Is it buggy for anyone? I’ve been trying to code an autonomous for swerve using some math and ether’s swerve. It all should work, but sometimes, without changing the code (or changing code that should not affect the autonomous at all), the results of the autonomous differ from time to time. Recently, I coded it to just move a few times, and it worked in the beginning, but when I changed code that literally should have had no effect on the autonomous code, it decided to just do fewer movements than it was doing before. I’ve been trying to figure out what the issue is with the code, and I can’t come to any conclusion because I’m sure it should work, so I’m just wondering if anyone has any similar problems with coding java autonomous and it being buggy.
just added the java files. its a lot to go through, but all it is is just deriving the angle of half of a circular path using two distances in an ellipse, then driving an amount thats equal to the arc of the circle and incrementally turning towards the derived angle in order to make a semi-circle curved motion.
Thanks for adding the source code. Just a note that you’ll get more replies if you use (say) a GitHub link, rather than attaching a zip archive.
Do you know which movement’s it’s skipping? The ones at the start or at the end?
What was the change? Is it possible that your earlier changes were not making it to the robot? (Something I see a lot is that Visual Studio Code will get stuck in desktop mode, or the programmer will fail to notice a compilation error, and so code changes will apparently have no effect on the robot, and then they all take effect at once when deployment finally succeeds.)
Does the robot behave as expected when it’s up on blocks? (You might find it helpful to take a video of the wheels.)
I recommend that you add logging to the initialize and end methods of your commands (Turn and EtherAutoCommands) so you can find out if they’re actually being run and with what parameters.
Is SmartDashboard/ShuffleBoard showing anything useful?
Probably not your immediate problem, but I notice you are not using requirements anywhere. This will cause you problems when you try to have both autos and an arcade drive.
Im using the SequentialCommandGroup SwrvLeftRight for the autonomous, when I changed
vars.mod1 = setDirection(tlDeg(), vars.mod1); vars.mod2 = setDirection(trDeg(), vars.mod2); vars.mod3 = setDirection(blDeg(), vars.mod3); vars.mod4 = setDirection(brDeg(), vars.mod4);
(this just finds the shortest path to an angle for the turn motors and changes the direction of the driving wheel according to where the wheel is angled)
In the MkSwerveTrain function EtherAutoSwerve, which the autonomous uses to drive, it decided to do four less moves in the autonomous code (two less turn resets and two less actual moves)
I’ll try putting System.out.println’s in the autonomous initialization and ending, and also try the autonomous with the robot off the ground when Im able to work on the robot. Thank you for the advice.
Sorry for the late response. Found out the problem was that the driving motors sometimes don’t reset their position. Should I make a while loop that resets the motors until they are 0 in the auto init?
I would be very hesitant to put a long-running, potentially-endless loop anywhere in the main event thread.
I assume you’re talking about the calls to setSelectedSensorPosition in startDrive. In order to get a better handle on what’s going on, you might like to use the variant that takes a timeout and then log the error code returned.
You might also consider, instead of resetting the sensors through the match, just store the start position and then subtract it in MkSwerveTrain.isFinished. If you reset your encoders continually, apart from the apparent possibility of failure, you prevent those encoders from being used for other purposes (such as dead reckoning).
I could have sworn I had this situation so I’ve been adding a brief wait/sleep after reset in teleopInit before using in teleopPeriodic. Then recently I read a thread complaining about simulation position reset not being right and CTRE says that shouldn’t happen and had some code to test with. I used their test code and it worked perfectly to reset position at the right time (essentially immediately and not in simulation - for real). So maybe my memory is playing tricks or maybe I see the sometimes doesn’t reset, too.
I think the status frame 2 update time needs to be at least as short as your iterative robot cycle time and yours is almost twice as long. Changing that to 20 from 35 might help.
And the advice to use the timeout and check errors is stellar! I borrowed others’ code from CD to make it easy. Something like this below. Put check() after every CTRE command. Use the true argument for one-time configs and false for methods in loops like the velocity set. I also added the retry 5 times that another team used.
flywheelMotor.setSelectedSensorPosition(0, pidIdx, TIMEOUT_MS); // start at 0 position
errors += check(flywheelMotor, “set sensor position”, true);
/** Check the TalonFX function for an error and print a message
*
@param TalonFX
@param message to print
@param printAll flag to print all (true) or just errors (false)
@return 1 for error and 0 for no error
*/
public static int check(TalonFX motorController, String message, boolean printAll)
{
var rc = motorController.getLastError();
if(rc != ErrorCode.OK || printAll)
{
System.out.println("[Talon] " + message + " " + rc);
}
return rc == ErrorCode.OK ? 0 : 1;
}
if(errors > 0)
{
DriverStation.reportError(“[Talon] failed to initialize flywheel motor controller on CAN id " + flywheelMotorPort, false);
System.out.println(”[Talon] failed to initialize flywheel motor controller on CAN id " + flywheelMotorPort);
}
The CD formatting did a little damage as * became bullet.
I see there is a Phoenix update recently that I had not installed. It might help you. I’d check for the latest since this post might be superseded, too.