Chief Delphi - WCD vs. Swerve

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)

- - WCD vs. Swerve (http://www.chiefdelphi.com/forums/showthread.php?t=98833)

Re: WCD vs. Swerve

Quote:

Originally Posted by JamesTerm (Post 1094170)

Oh and each vector is divided by 4.

Just to be clear: There is a divide-by-4 (which divides all 4 terms) in the original equations I posted:

Quote:

omega = ((sFR*cos(atan2(W,L)+pi/2-aFR)+sFL*cos(atan2(-W,L)+pi/2-aFL)
+sRL*cos(atan2(-W,-L)+pi/2-aRL)+sRR*cos(atan2(W,-L)+pi/2-aRR))/4)/
(sqrt(L^2+W^2)/2);

Re: WCD vs. Swerve

Quote:

Originally Posted by Ether (Post 1094173)

Just to be clear: There is a divide-by-4 (which divides all 4 terms) in the original equations I posted:

Yes... I've changed my equation to do the divide last, as this is more efficient. One thing I wanted to point out is that these equations can work with linear velocity instead of angular, but more importantly which ever it is all the variables must be the same... This caught me off guard in my debugging as my RCW needed to be converted to linear velocity, and my omega needed to be converted back:

So I do this

Code:

        //const double R = sqrt((L*L)+(W*W));

        const double R = GetWheelDimensions().length();



        double RCW=GetAngularVelocity(); //in radians

        double RPS=RCW / Pi2;

        RCW=RPS * (PI * R);  //R is really diameter



//and this:

        AngularVelocity=(omega / (PI * D)) * Pi2;

I have made a better demo today after fixing a lot of bugs from the first one here:
http://www.termstech.com/files/SwerveDriveDemo2.wmv

I was able to use similar equations for the tank drive:

Code:

        m_LeftLinearVelocity = FWD + RCW;

        m_RightLinearVelocity = FWD - RCW;



        //const double FWD = (LeftLinearVelocity*cos(1.0)+RightLinearVelocity*cos(1.0))/2.0;

        const double FWD = (LeftLinearVelocity + RightLinearVelocity) / 2.0;

        //const double STR = (LeftLinearVelocity*sin(0.0)+ RightLinearVelocity*sin(0.0))/2.0;

        const double STR = 0.0;



        const double omega = ((LeftLinearVelocity) + (RightLinearVelocity*-1))/2.0;

And so now the tank drives much better too!

Re: WCD vs. Swerve

Quote:

Originally Posted by JamesTerm (Post 1092574)

I have a question for you... (or anyone else that can answer)... Does your robot work in a way where you can submit desired angles to each wheel independently? (I presume that is what the *independent* means in your statement).

Technologically, yes. We do not have inputs on the Driver's Station that can literally say, "right-front at 40deg", "left-rear at 60deg", etc, but in theory we have both the hardware and the programming input & feedback to move any wheel at any angle and speed (limited by motors/gearboxes) we'd like. Really we just steer in "modes", e.g. crab, snake, and some useful spins (who's radius we can control).

Quote:

Originally Posted by JamesTerm (Post 1092574)

If so, how do you sense when the rotation has reached its angle? potentiometer? IIRC Bomb Squad uses windows motors on each wheel to control the swerve. From what I have heard, other teams use a rod to swerve both front wheels the same amount, and can then have a manual control setup doing it this way.

Our swerve rotation is controlled by Banebot RS-540's on 256:1 4-stage planetary gearboxes, one per module. (We used window motors last year.) We use Vishay encoders (981HE0B4WA1F16) which we can hand-adjust every once in a while as needed. This works quite well (way better than the Cherry AN8's), though the PID isn't perfect yet and the backlash is especially obvious in autonomous.

More: Team 1640's LogoMotion Drive Train

Re: WCD vs. Swerve

Quote:

Originally Posted by Siri (Post 1094529)

More: Team 1640's LogoMotion Drive Train

Thanks very much for this link... I hope our team will be brave enough to try something like this for off-season.

It seems like that swerve-drive teams are of a rare breed. ;)

Re: WCD vs. Swerve

Quote:

Originally Posted by JamesTerm (Post 1094369)

I have made a better demo today after fixing a lot of bugs from the first one here:
http://www.termstech.com/files/SwerveDriveDemo2.wmv

Interesting simulation, and a potentially useful teaching tool.

Couple of questions:

1) why did you restrict steering to 270 degrees

2) it would be helpful if you would add some sort of indicator on each wheel to show which direction it is spinning*.

* yes, I see the red and green. these indicate which is the forward and reverse direction for the wheel, not which way the wheel is actually spinning at the moment.

Re: WCD vs. Swerve

Quote:

Originally Posted by Ether (Post 1094620)

Couple of questions:

1) why did you restrict steering to 270 degrees

2) it would be helpful if you would add some sort of indicator on each wheel to show which direction it is spinning*.

[/i]

I did the 270 to handle using potentiometers at 1:1 ratio. I can easily remove this but Id want to understand what reliable sensor could allow free movement.

As for direction of the wheels there are treads " <-- that rotate where height is portraited by white on top and gradient to dark grey on bottom. Unfortunately the wmv quality makes this difficult to see... I should put the mp4 of this on you tube at some point.

Re: WCD vs. Swerve

Quote:

Originally Posted by JamesTerm (Post 1094646)

Id want to understand what reliable sensor could allow free movement.

See the comment about Vishay encoders here:

http://www.chiefdelphi.com/forums/sh...9&postcount=63

others here:

http://www.chiefdelphi.com/forums/sh...75&postcount=3

Re: WCD vs. Swerve

Quote:

Originally Posted by Siri (Post 1094529)

Really we just steer in "modes", e.g. crab, snake, and some useful spins (who's radius we can control).

I just finished watching a video we shot of our 8th match at the championship... we played defense against your red alliance. It is neat to see this swerve robot in action it was able to out maneuver our attempts to block. The only weakness was when switching from forward to strafe delayed the robot enough for the tank drive (perpendicular) to be able to catch up, but then a rotating maneuver put an end to that.

Who knows... maybe in 2012 we'll be on the same alliance. ;)

Re: WCD vs. Swerve

Quote:

Originally Posted by JamesTerm (Post 1094730)

Who knows... maybe in 2012 we'll be on the same alliance. ;)

And that's what I love about FIRST. :)

Re: WCD vs. Swerve

Quote:

Originally Posted by JamesTerm (Post 1094730)

Yes, this drove me crazy from the driver's station all season. (Especially when the defense is so unrelenting!) We've been working on it for over a year now. I don't think it's inherent, but it's at least been stubborn. We're hoping to beat it this season. We'll see how it works when we play with each other at Champs! ;)

Re: WCD vs. Swerve

Quote:

Originally Posted by Siri (Post 1094820)

Yes, this drove me crazy from the driver's station all season. (Especially when the defense is so unrelenting!)

I've been thinking... it makes no sense to talk about the video without sharing it... so here it is:

www.termstech.com/files/WCDvsSwerve.wmv

I apologize on the low framerate... I REALLY need to find a free way to share high quality media (The original is AVCHD 1080i)... I'll look into this soon.

Check out towards the last 15 seconds when we attempt to block you for minibot deployment... cool stuff. :)

Re: WCD vs. Swerve

Quote:

Originally Posted by Siri (Post 1094820)

Try instantaneously reversing direction as you switch to strafe and start turning the wheels. That way, instead of arcing into the defender, or waiting for the wheels to finish spinning before moving, you arc backwards and give yourself a bit of space.

Re: WCD vs. Swerve

Quote:

Originally Posted by Chris is me (Post 1094828)

That's really interesting, thanks. We'll work back through the driver movements. I'm told at least part of the pause is in the code, but paying attention to inertia never hurts.

James: Thanks, I was hoping you had the video to share. We don't have any championship video. Could I try to find a way to get the higher resolution version?

Re: WCD vs. Swerve

Just wondering, is there such thing as an "East Coast Drive"?

Re: WCD vs. Swerve

Quote:

Originally Posted by Siri (Post 1094843)

That's really interesting, thanks. We'll work back through the driver movements. I'm told at least part of the pause is in the code, but paying attention to inertia never hurts.

Pause in the code? I think I may throw an idea to you that can help with that! First let me show you my code snip of what I do here:

Code:

void Swerve_Robot::InterpolateThrusterChanges(Vec2D &LocalForce,double &Torque,double dTime_s)

{

        //Now the new UpdateVelocities was just called... work with these intended velocities

        for (size_t i=0;i<4;i++)

        {

                const double IntendedDirection=GetIntendedVelocitiesFromIndex(i+4);

                double SwivelDirection=IntendedDirection;  //this is either the intended direction or the reverse of it

                const Ship_1D &Swivel=m_DrivingModule[i]->GetSwivel();

                const double LastSwivelDirection=Swivel.GetPos_m();

                double DistanceToIntendedSwivel=LastSwivelDirection-SwivelDirection;

                NormalizeRotation(DistanceToIntendedSwivel);

                DistanceToIntendedSwivel=fabs(DistanceToIntendedSwivel);



                if ((DistanceToIntendedSwivel>PI_2) || (SwivelDirection>Swivel.GetMaxRange()) || (SwivelDirection<Swivel.GetMinRange()) )

                {

                        SwivelDirection+=PI;

                        NormalizeRotation(SwivelDirection);

                        double TestIntendedFlipped=IntendedDirection+PI;

                        NormalizeRotation(TestIntendedFlipped);



                        //If we flipped because of a huge delta check that the reverse position is in range... and flip it back if it exceed the range

                        if ((SwivelDirection>Swivel.GetMaxRange()) || (SwivelDirection<Swivel.GetMinRange()) ||

                                (TestIntendedFlipped>Swivel.GetMaxRange()) || (TestIntendedFlipped<Swivel.GetMinRange()))

                        {

                                SwivelDirection+=PI;

                                NormalizeRotation(SwivelDirection);

                        }

                }

                //Note the velocity is checked once before the time change here, and once after for the current

                //Only apply swivel adjustments if we have significant movement (this matters in targeting tests)

                if ((fabs(LocalForce[0])>1.5)||(fabs(LocalForce[1])>1.5)||(fabs(m_DrivingModule[i]->GetDrive().GetPhysics().GetVelocity()) > 0.05))

                        m_DrivingModule[i]->SetIntendedSwivelDirection(SwivelDirection);

                const double IntendedSpeed=GetIntendedVelocitiesFromIndex(i);



                //To minimize error only apply the Y component amount to the velocity

                //The less the difference between the current and actual swivel direction the greater the full amount can be applied

                double VelocityToUse=cos(DistanceToIntendedSwivel)*IntendedSpeed;



                m_DrivingModule[i]->SetIntendedDriveVelocity(VelocityToUse);

                m_DrivingModule[i]->TimeChange(dTime_s);



                const double CurrentVelocity=m_DrivingModule[i]->GetDrive().GetPhysics().GetVelocity();

                const double CurrentSwivelDirection=Swivel.GetPos_m();

                //if (i==0)

                //        DOUT4("S= %f %f V= %f %f",CurrentSwivelDirection,SwivelDirection,CurrentVelocity,VelocityToUse);



                //Now to grab and update the actual swerve velocities

                //Note: using GetIntendedVelocities() is a lesser stress for debug purposes

                #if 1

                m_Swerve_Robot_Velocities.Velocity.AsArray[i+4]=CurrentSwivelDirection;

                m_Swerve_Robot_Velocities.Velocity.AsArray[i]=CurrentVelocity;

                #else

                m_Swerve_Robot_Velocities=GetIntendedVelocities();

                #endif

        }



        __super::InterpolateThrusterChanges(LocalForce,Torque,dTime_s);

}

Check out this line in particular:

Code:

                //To minimize error only apply the Y component amount to the velocity

                //The less the difference between the current and actual swivel direction the greater the full amount can be applied

                double VelocityToUse=cos(DistanceToIntendedSwivel)*IntendedSpeed;

Let me explain this line here... Imagine if you will the one scene where you where strafing us and then want to move folward... Let's assume for the sake of arguement the driver was pushing staight forard (this will help visualize the solution)... During each frame that transitions the angle from 90 to 0 degrees (where 0 is forward)... ANY Y component of the vector will be executed with a tradeoff of minimal error. In this case the robot would slightly arc on the X component to give you the most Y you can have during the transition. It should be also noted that it also will determine the correct + or - direction of the wheels as well (no branching Yay!). I hope this makes sense... In my demo when I strafe and rotate at the same time... the key for this success is this line of code where every opportunity to fulfill the x component of the vector will happen.

Quote:

Originally Posted by Siri (Post 1094843)

James: Thanks, I was hoping you had the video to share. We don't have any championship video. Could I try to find a way to get the higher resolution version?

I will talk with my friend Jeremy tonight about this. I did resubmit the wmv file with a lower 320x240 and found that framerate is much better, so if you have the 640x480... go back to the link and try it again... It looks good on a phone too. ;)

I'll keep you posted... I WILL get this to you somehow! :)