Quote:
Originally Posted by Gdeaver
I like the module concept. Swerve is complex and many modes of failure . With independent modules if something goes wrong don't fix it on the bot. Remove the module and replace it. Fix it later. We can remove a module and have the new one installed in less than 10 Minutes. How fast can you remove one of you modules?
Yes, you can use a quadrature encoder with indexing for the steering but , why not use an absolute encoder? The C-rio only has 4 4x encoders. Why not save them for velocity needs? I believe the code is cleaner with absolutes.
You mention that you are not doing least distance calculations for steering angle. A properly coded least distance algorithm will not allow the wheels to be in a conflicting position. There is always a smooth transition from current position to the new set points. It also makes the steering much more responsive.
If you using window motors, I hope you have removed the locking pins and are using victors.
We have not found that multi-speed is needed. It also is 1 more degree of freedom for the driver to have to master.
Field centric control? From our experimentation I do not believe there is an affordable gyro or INU that can remain accurate over the time frame of tele op. However we will have a gyro on the bot for 2012 to assist with autonomous navigation. The one problem with swerve is the robot doesn't like to go straight with dead reckoning for very far.
Why go thru the pain and suffering of swerve development? Because it is hard. It's amazing how the stress of swerve development has made our students and team grow intellectually and from and organization perspective. Also , it was pure joy when a tank bot came flying at us from across the field and our driver executed the side slip move. We also can have our way with mecanum bots.
Do you have a 3d model of the module that you could post. This is ours let's see yours.
http://wiki.team1640.com/index.php?t...II_Drive_Train |
Lots of questions here.
First, we'll likely never build a robot without shifting. The speed it allows without compromising defense ability and the ability to withstand defense is awesome.
We're using incremental encoders so that we never, ever have to zero encoders. We had the zeroing of absolute sensors as painless as possible last year, but still would like to take that few minutes of time to zero time. The other advantage of incremental encoders is an incredible increase in precision over analog sensors. This is primarily a time saving measure (on that note, we can easily replace a wheel module, or an entire corner module, within a 5 minute period to fit in a time out). I used to be a huge fan of absolute sensors for absolute systems, but we've changed our mind recently; we'll likely never use another absolute sensor for any FRC system.
The first iteration of code did the least distance for steering, but didn't flip drive. We are now flipping drive as well. This has greatly increased the response and handling of the system. Since it is solved for on an individual wheel basis, it is still possible to have momentary disagreement between wheels (but a much more rare occurrence). I'm unsure what you're saying exactly, as each wheel always has a smooth transition and the PD steering works great, but they can cross each other if the situation is right (or wrong I guess). We've barely put any testing time on it, so we'll make a more informed decision of where to go from here after some testing.
We will not be using field-centric as the primary driving mode, but it will be there as an option. The code is trivial really. We'd likely only ever use it as a button
Akash, the encoders we're using are leftover s4's from usdigital.