The first thing I would try to do is have the simulated wheel speeds not jump around. Basically, the minimum time it takes for each wheel to get to its maximum speed shouldn’t be 0 seconds (like it is right now). So if you’re at 0% speed and you want to go to 50% speed, let’s say that might take .5 seconds. This would mean you would basically have an acceleration of 100% per second: It takes you 1 second to get to 100% speed.
This year with our custom simulation, we used the Box2D physics library with libGDX. Although we used swerve, it can also be applied to tank: Define where each wheel is and constrain each wheel to the robot’s main body. Periodically update the velocity and angle of each wheel (for tank it would only be velocity). The box2d library took care of realistically moving and rotating the body.
I’m sure there’s a reasonable was to do this with hopefully simple math, but a full on physics engine would take some of that work away and might even give you more options.
Setup part of our code
Setting the velocity of a single wheel
Acceleration logic
Sorry that the simulation part of our code is in Kotlin, hopefully you can understand it
I’m not sure how well box2d works without using libGDX, but it might be worth trying. However, there is a learning curve for it.
I’m guessing that more people will want to try what you’re doing next year as the Field2d thing was added in the middle of the season. I’d be interested to see if someone will eventually make a PR with an example for a simulated drivetrain. I might try and contribute to the WPI simulation stuff, I’m not sure yet.