After watching many of the week 1 events, it seems a lot of teams did either nothing in auto, scored a piece and stayed put, tried to get mobility and got a penalty, or successfully got mobility but got in the way of other potential autos.
This lead me to the theory that auto balancing is not only easier than mobility, it is more accessible too.
So we set out to write a simple auto balancing routine that uses no sensors except the built in accelerometer on the RoboRIO, with no PID, and is simple and quick to tune. Works for RoboRIOs in any orientation (although RoboRIOs mounted high off the ground may experience more acceleration).
Why should you use this?
Automobility is hard to do in a way that is both alliance partner friendly in terms of not touching game pieces and also not getting a penalty for crossing half. There just isn’t a good window of time or angle that reliably gets this done. Even if you do its worth 3 points. Scoring one game piece low and balancing is worth 15 if you engage, and 11 if you are just docked, and the endgame balancing requirements for RP is the same if you dock but don’t engage. The whole thing can easily take less than 10 seconds. It’s very easy to tune by changing these parameters:
Me and another team at the competition I’m in are having some difficulties trying to get it to work in command based structures can you show an example of how to get it working in command based?
I believe it should be as simple as creating an autoBalance object in your command. And then in execute(), call it like the other example, make sure you set your motors to the speed. I didn’t in the example below because I wanted to give you a quick answer.
So I have it basically exactly the same as you just slightly changes setSpeed() command due to our drivetrain. I have also just changed the autoBalance to extend SubsystemBase. It will drive the right side but the left doesn’t move.
You mentioned one side moving but the other wasn’t. In your code you give the same values to both sides. Maybe the issue lies somewhere in the motor controller you are writing to. What happens if you just put a constant like 0.2 in your left side motor write. Make sure the wheels are off the ground when testing. Does the left side spin?
I got both sides doing the same now I don’t remember what I did to do it but I am still getting a motorsafety saying that it isn’t updated often enough. Every other drive based command we have works I think it may be something with the setSpeed command.
If I recall, motor safety happens if you don’t when a motor write doesn’t happen every frame. Could be caused by the score and balance being expensive. Latest commit should have more efficient code
I made a new timeBased specifically to remove all variables no longer have a motorSafety however it only twitches the wheels. I should also note our rio is mounted vertically and upside down.
Having a motor write in your RobotPeriodic, and another in autonomous periodic will do this. Every frame you are setting the motor to a value and setting it to zero, causing twitching. Move the contents of this function to TeleopPeriodic
Ok so update, made the change to teleopPeriodic and was able to put the values in smart dashboard had to change the tilt by about 95 degrees and it now slows when lifted have yet to put it on the charge station for full test but appears to be functional just a small problem when in autonomous it causes motorSafety errors. However in teleop we have no motorSafety errors.
Since the finals are happening we won’t be able to get it tested before we leave as there is too much going onto get a robot through to the test field.
