We noticed that changing to break mode on the falcon 500s yields much better control in some of our pid loops so that the drivetrain does not coast past the setpoint. We are trying to change the modes on the fly in our code here before and after the “turntotarget” command:
Your isFinished is returning false, meaning the command scheduler thinks the command is still running and won’t move on to the next command. For something like this you’d either want it to always return true (so it runs execute once) or add a small timeout for setting the mode through CAN, though I don’t think that would be necessary.
I would love to learn more on why you think using coast at all for your drivetrain. We’ve never done this before, so I wanna know, @iwumbo , what we are missing?
I literally just learned about brake and coast today so its very possible I am misinformed. But I was told that brake mode uses significantly more electricity and would risk the motor burning out a lot more in a match. Considering our robot this year is using cims, using brake mode on srxs would very likely burn out the motors over the course of competition. Which is why we would only use brake mode when we need the precision the most.
If you want you can run your own experiment to test current usage in both modes. Your driver’s station does a lot of helpful logging so you can convince yourself which is the best approach.
Keeping your drivetrain in coast mode could be risky cuz when you disable your robot it maintains it’s inertia, further coasting to whatever danger is in it’s path.
Brake mode connects the motor leads together, basically feeding the generated electricity from the movement of the motor back into itself to resist motion. It does not use any electricity from the battery.