![]() |
Re: pic: FRC973 Presents Emperor Swerve
I've been wanting to build this drivetrain for years, and then you come along and beat me to it. So it's back to the drawing board for me...maybe I'll sketch out a flying robot this time.
(Nice work; send CAD files!) |
Re: pic: FRC973 Presents Emperor Swerve
It's absolutely gorgeous. Well done!
|
Re: pic: FRC973 Presents Emperor Swerve
Adam,
you guys have certainly stepped it up doing great things with your team. Wish I could witness it at the off-season event. Glenn |
Re: pic: FRC973 Presents Emperor Swerve
Can someone explain in simple terms what you mean by translation and rotation?
|
Re: pic: FRC973 Presents Emperor Swerve
Quote:
Translation: Motion in a single direction (either front/back or side-side, or in the case of an omnidirectional drivetrain, some line in between). If the point of rotation happens to be translating as you rotate, you are pulling off a very tricky move--that sort of motion is usually reserved for things like frisbees, not stuff that stays on the ground. |
Re: pic: FRC973 Presents Emperor Swerve
Richard, our robot can drive any direction it wants to, and at the same time rotate. Much like the videos Madison posted.
Quote:
|
Re: pic: FRC973 Presents Emperor Swerve
very nice
mike d |
Re: pic: FRC973 Presents Emperor Swerve
Quote:
1) rotation of the vehicle around that point, and 2) translation (motion) of that point in the forward/reverse direction (with respect to the vehicle), and 3) translation (motion) of that point in the left/right direction (with respect to the vehicle). Some examples: a) a car driving forward in a straight line. The forward translation is non-zero, and the rotation and sideways translation are both zero. b) the moon going around the Earth. Call the "front" of the moon the part that is facing the Earth. The forward translation is zero, the sideways translation is non-zero, and the rotation is non-zero (it is equal, in radians per second, to the sideways translation speed divided by the length of the radius of the moon's orbit). Here are some example diagrams of how Ackermann, rotary, "moon", and "dosado" motions can be described in terms of the 3 degrees of freedom. 1this usually makes the inverse kinematics easier |
Re: pic: FRC973 Presents Emperor Swerve
Quote:
I remember accomplishing this on our robot, but it was a very tough maneuver. |
Re: pic: FRC973 Presents Emperor Swerve
Quote:
|
Re: pic: FRC973 Presents Emperor Swerve
Quote:
|
Re: pic: FRC973 Presents Emperor Swerve
Is there a video of the robot performing yet? This looks really Awesome though!
|
Re: pic: FRC973 Presents Emperor Swerve
Quote:
If you have a stable and reliable gyro, it can be used to convert "field-centric" translation commands into the corresponding robot-centric translation commands. Some maneuvers that would otherwise take a great deal of driver practice and skill can be greatly simplified by doing this. The way a field-centric command works is this: 1) The driver uses the joystick (or other input) to command the vehicle to go in desired direction (with respect to the field)If the driver is commanding a constant field-centric direction and speed, and the vehicle is simultaneously rotating, then the computer is continuously converting that constant field-centric command into the time-varying fore/aft and port/starboard robot-centric commands necessary to keep the vehicle moving in the direction and speed commanded by the driver, regardless of the vehicle's angular orientation. So the driver can command field-centric "forward" (usually defined as "downfield" - away from the driver station) and the vehicle will travel in a straight line in that commanded direction regardless of the independently commanded vehicle rotation (subject to the caveats mentioned earlier). |
Re: pic: FRC973 Presents Emperor Swerve
Adam,
You mentioned that one of the "d'oh" problems you encountered was wheels momentarily opposing one another as the pods rotated to their commanded angles. What algorithms do you plan to use to correct for this? (I suspect I know the answer, but it would be a great topic for discussion here, as this is one of the common "gotchas" that makes swerve programming much, much more complicated than just implementing the inverse kinematics) Thanks |
Re: pic: FRC973 Presents Emperor Swerve
Quote:
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. |
| All times are GMT -5. The time now is 16:53. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi