pic: FRC973 Presents Emperor Swerve

[AdamHeard]

We have a working idea of a 4 wheel path planner that assures we completely avoid the issue. The downside is that you are spending a little bit longer steering in most cases.

In the initial code, we didn't change drive directions to make it easier on the steering. We realized this is totally against our team's philosophy and we'll flip drive directions to reduce response times. If it breaks, we'll make it stronger. This changes our maximum error from 180* to 90*, already greatly helping the problem.

We also plan to limit the drive output as a function of error (starting with cosine because it's convenient, maybe testing other functions. I think we shouldn't ever drive with more than 45* of error, and scale up from there). This has the added effect of avoiding the side scoot.

We feel with these two changes we may be able to avoid the tediousness of a 4-wheel path planner, but testing will tell. Driver practice should massively help as well, as they'll learn how to properly drive it for maximum response.

My fear is we will have to start limiting drivespeed as a function of the error any wheel happens to be pointing at as well, our current code lets a wheel with zero error go full power when pointing at a wheel completely normal to it. Now, this case is unlikely to develop, but only testing will tell.

At some point we plan to record all important values of the robot, so we can pull it off the robot to graph. This will allows to see what bad cases we're running into, and also what cases the driver is routinely driving. Hopefully we'll be able to optimize the code to improve this.

Our team, like several other west coast teams, is used to fast and responsive 6wd's that never feel laggy. Our goal is to get the crab to where a driver from any of these teams wouldn't complain about the "lag" of crab. It's a high goal, but when we reach it it should result in one heck of a system.

I'm really rambling now, but as a controls/mechatronics concentration in my Mechanical Engineering major, I love this robot. More than any system we've made in the past I've really been able to show the kids what it is that I do, and although they can't derive some of the higher level stuff on here, they all understand the concept of it. It's also spurred one of the biggest design/controls debates we've ever had on how exactly we want to solve the path problem, with kids really coming up with some good ideas (and even spotting the crashing case well before it even occurred to me!).

Originally Posted by Ether

Exactly.

I see two general classes of solutions to this problem:

1) rate-limit the driver commands. advantage: effective, and simple to implement. disadvantage: possibly poor responsiveness

2) foresake independent control of each pod... make the control algorithm for each pod be dependent on what the other pods are doing so that their actions are coordinated. advantage: potential for better performance than option1. disadvantage: may take quite a bit of thought and debugging to get something that works reliably under all situations; and there may still be latent bugs waiting for the right Murphy moment to bite.