Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Extra Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=68)
-   -   pic: FRC973 Presents Emperor Swerve (http://www.chiefdelphi.com/forums/showthread.php?t=97568)

AdamHeard 27-09-2011 20:56

pic: FRC973 Presents Emperor Swerve
 

O'Sancheski 27-09-2011 20:57

Re: pic: FRC973 Presents Emperor Swerve
 
So when are you going to post the cad for this so that all of us can explore the amazing robot that you guys built?

Andrew Lawrence 27-09-2011 21:47

Re: pic: FRC973 Presents Emperor Swerve
 
I think I may have fallen in love! Seriously, this thing looks amazing!

Justin Montois 27-09-2011 22:34

Re: pic: FRC973 Presents Emperor Swerve
 
Very well done. Looks awesome.

Thermal 27-09-2011 22:52

Re: pic: FRC973 Presents Emperor Swerve
 
Very impressive build. Congratulations on your offseason, the results are outstanding

Tom Bottiglieri 27-09-2011 22:53

Re: pic: FRC973 Presents Emperor Swerve
 
Wow, very nice! What other offseason are you guys doing?

AdamHeard 27-09-2011 23:01

Re: pic: FRC973 Presents Emperor Swerve
 
We have 6 weeks until The Madtown Throwdown in Fresno, which is shaping up to be a ridiculously stacked event (254, 254, 968, 971, 971, 973, 973, 973, 1323, 1323... that's a lot for the west coast!). We plan to be well practiced and well coded for this event, we had 30 seconds of practice and maybe 5 hours of code time before this previous weekend's event.

Quote:

Originally Posted by Thermal (Post 1078935)
Very impressive build. Congratulations on your offseason, the results are outstanding

Haha thank you, but all congrats should go to 1538 and our comp bot. The crab was limping all day due to a glaring oversight on our part that resulted in tripping breakers. Easily fixed, but in the heat of the moment we didn't immediately spot the solution.

So, for future reference everyone... Path DOES matter if it possibly results in wheels pointing at each other driving full speed.... Boom 120 main breaker trip.

techtiger1 27-09-2011 23:26

Re: pic: FRC973 Presents Emperor Swerve
 
Gosh is that beautiful. Great job 973 I am very interested to hear more about the iteration of this swerve drive.

Mk.32 27-09-2011 23:31

Re: pic: FRC973 Presents Emperor Swerve
 
We saw this at the Fall Classic, looked very impressive. Totally blew the swerve drive were are designing out of the water. Hope to see it again soon, and congrats on your win!

emekablue 27-09-2011 23:53

Re: pic: FRC973 Presents Emperor Swerve
 
I'm impressed, this is good. I hope to see it up close at the Throwdown.

Mark Sheridan 28-09-2011 00:11

Re: pic: FRC973 Presents Emperor Swerve
 
Wow! Really cool. omnidirectional swerve with two speeds! That is definitely the ultimate drivetrian.

I notice the CIM has two gears on it. I was wondering if you can shed some light on the design process of making a compact two speed swerve. Love to see more close up pictures.

thank you for posting

AdamHeard 28-09-2011 00:15

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Mark Sheridan (Post 1078952)
Wow! Really cool. omnidirectional swerve with two speeds! That is definitely the ultimate drivetrian.

I notice the CIM has two gears on it. I was wondering if you can shed some light on the design process of making a compact two speed swerve. Love to seem more close up pictures.

thank you for posting

We'll get a picture of a module removed this weekend. It's kind of cool the swerve is really just 4 modules and a frame. The modules really are "IT".

Also, to answer O'Sancheski's question, we'll likely post a video, photoalbum and .stp file closer/after the next offseason event when the robot is "done".

rcmolloy 28-09-2011 01:30

Re: pic: FRC973 Presents Emperor Swerve
 
I still like dungeness crab much better Adam. I'll make sure that will be the name for the potential 2012 bot.

AdamHeard 28-09-2011 01:32

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by rcmolloy (Post 1078960)
I still like dungeness crab much better Adam. I'll make sure that will be the name for the potential 2012 bot.

Dungeness makes no sense, with our last crab being King Krab. Emporer is like the only thing greater than a king. Already got a name for the 2012 bot as well ;)

Thermal 28-09-2011 01:57

Re: pic: FRC973 Presents Emperor Swerve
 
After looking through more of your teasers, and seeing those constant force springs coupled with the R&P, I have to say this is by far the coolest lift i've seen in FIRST. I am sure it runs like a dream.

^^ Eagerly awaiting video of the lift, it must be FAST

Hawiian Cadder 28-09-2011 07:15

Re: pic: FRC973 Presents Emperor Swerve
 
No mini-bot?

=Martin=Taylor= 28-09-2011 08:17

Re: pic: FRC973 Presents Emperor Swerve
 
Very impressive Adam, this is incredible.

The design is clean, simple, and very well executed. Pulling off both translation and rotation at once is very impressive. A swerve of this caliber has real competitive advantage (as compared to 60% of the swerves that get built).

I hope they give you 4 window motors next year so you can do this.

Jared Russell 28-09-2011 08:20

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1078961)
Dungeness makes no sense, with our last crab being King Krab. Emporer is like the only thing greater than a king. Already got a name for the 2012 bot as well ;)

Kaiser Krab?

EricH 28-09-2011 09:12

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Jared341 (Post 1078983)
Kaiser Krab?

Nah, that's the same level as King Krab.

So how close is Emperor Swerve to unicorn drive?

Akash Rastogi 28-09-2011 09:14

Re: pic: FRC973 Presents Emperor Swerve
 
King Krab? Emperor Krab?

You need a Demo-Krab or Aristo Krab. (HA, I'm funny).

Adam, did you guys end up using the shifting on the crab drive? Was it worth it?

Chris is me 28-09-2011 09:15

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by EricH (Post 1078993)
So how close is Emperor Swerve to unicorn drive?

It is a "Unicorn" drive. 4 motor drive and 4 motor steering with infinite rotation.

JesseK 28-09-2011 10:16

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

fully omnidirectional swerve that can translate and rotate simultaneously through all orientations
I'm surprised no one has challenged this claim; such tornado-like moves are the holy grail of FRC movement (IMO) yet I haven't found a single video of a robot actually performing a 360-degree translate-and-rotate move. This drive train is definitely setup to perform the maneuver with its independent controls, and I'd love to see it work -- it's like a video game come to life, tbh.

I like how the crab drive required minimal CNC work. Was the main coaxial shaft split up into plates? If so, you could easily call them poker chips because that's what they'd look like. What was the hardest part of the crab modules manufacturing implementation?

buildmaster5000 28-09-2011 10:22

Re: pic: FRC973 Presents Emperor Swerve
 
<draw hits floor>

Seriously, that is an impressive machine. Can't wait for pics of the elevator. I am curious what you did as far as programming the drive system is concerned. Someone must have spent a lot of time with vectors....

thefro526 28-09-2011 12:55

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by JesseK (Post 1079010)
I'm surprised no one has challenged this claim; such tornado-like moves are the holy grail of FRC movement (IMO) yet I haven't found a single video of a robot actually performing a 360-degree translate-and-rotate move. This drive train is definitely setup to perform the maneuver with its independent controls, and I'd love to see it work -- it's like a video game come to life, tbh.

I think no one has challenged that claim because on paper, this robot is fully capable of translating and rotating at the same time. I'm sure video will surface shortly of it running.

Also, Mecanum and Holonomic/Killough drives, if programmed properly can translate and rotate at the same time. I've seen some FRC robots do it before (2008 comes to mind), but never in full circles (really no reason to, not to mention that it's really hard to keep a constant radius while doing so.)

BJC 28-09-2011 13:04

Re: pic: FRC973 Presents Emperor Swerve
 
I spy with my little eye, a window motor in each module. I'm guessing those are for rotating the individual wheels.

What diameter wheels are being used on this"? It appears that they couldn't be much bigger than 4" Of course, smaller wheels makes for smaller modules and less gearing so that would make sense.

Brandon Holley 28-09-2011 13:12

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by thefro526 (Post 1079028)
I think no one has challenged that claim because on paper, this robot is fully capable of translating and rotating at the same time. I'm sure video will surface shortly of it running.

Also, Mecanum and Holonomic/Killough drives, if programmed properly can translate and rotate at the same time. I've seen some FRC robots do it before (2008 comes to mind), but never in full circles (really no reason to, not to mention that it's really hard to keep a constant radius while doing so.)

Madison posted a video a couple of years ago of their mecanum drive doing full rotations while translating. I'm trying to find it on youtube, but have been unable to as of yet.

It's definitely been done. Not often, but I've definitely seen it.

-Brando

Madison 28-09-2011 13:40

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Brandon Holley (Post 1079030)
Madison posted a video a couple of years ago of their mecanum drive doing full rotations while translating. I'm trying to find it on youtube, but have been unable to as of yet.

It's definitely been done. Not often, but I've definitely seen it.

-Brando

Our 2011 Octocanum can definitely rotate freely while translating -- I'm trying to find a good video of it doing so.

Edit: Here are two --

http://www.youtube.com/zorkinian#p/a/u/0/Jr-eglZBAHQ
http://www.youtube.com/zorkinian#p/a/u/1/sM8cixsE5fo

AdamHeard 28-09-2011 13:45

Re: pic: FRC973 Presents Emperor Swerve
 
Yes it shifts, we're so into the style of robots we've been building that there is no way we could give up shifting. It wasn't much work to integrate at all, just a little more weight.

We prefer to cal it a Emporer Swerve or West Cost Swerve instead of Unicorn Drive, Unicorn Drive's can't shift after-all ;)

The entire mechanical design focused on making programming/controls easier, and there are some cool features we plan to implement. Currently the separate incremental encoder and zeroing sensor allow us to never have to zero sensors by hand, or in code. We also plan to have code that detects an encoder failure, locks that wheel straight, and switches to a drivemode without strafe but still the ability to translate forward/back and steer (We had similar functionality on our arm this year). We really are aiming to make this as reliable as possible.

Quote:

Originally Posted by JesseK (Post 1079010)
I'm surprised no one has challenged this claim; such tornado-like moves are the holy grail of FRC movement (IMO) yet I haven't found a single video of a robot actually performing a 360-degree translate-and-rotate move. This drive train is definitely setup to perform the maneuver with its independent controls, and I'd love to see it work -- it's like a video game come to life, tbh.

I like how the crab drive required minimal CNC work. Was the main coaxial shaft split up into plates? If so, you could easily call them poker chips because that's what they'd look like. What was the hardest part of the crab modules manufacturing implementation?

We currently *could* make that move, but it'd be difficult as the drive would have to continuously change the translation direction. We have the code written for a gyro offset to allow this to switch into field-centric and seamlessly implement the move, but have yet to get a gyro on there. We've really only just barely got to what's pictured, and are shooting for normal functionality first. Low angle (<30*) rotation while driving has been tested and is pretty intuitive.

The main coaxial shaft is actually a very simple lathe part, it's got less operations than the parts you make in the intro to machining classes here at Cal Poly. The Only CNC'd part I believe is what we call the module tophat. We could have made them on our mill, but wanted to pocket them and there are also a few tight tolerances on them. We also don't really count 2d (Water/laser) cutting as CNC as the time investment involved is vastly different.

AdamHeard 28-09-2011 13:54

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by buildmaster5000 (Post 1079013)
<draw hits floor>

Seriously, that is an impressive machine. Can't wait for pics of the elevator. I am curious what you did as far as programming the drive system is concerned. Someone must have spent a lot of time with vectors....

I derived the steering equations, and they actually converged to exactly what Ether had posted in his whitepapers. This makes sense, as it's the same physical system, but it was really cool to see.

Ether 28-09-2011 14:16

Re: pic: FRC973 Presents Emperor Swerve
 

By now the inverse kinematics1 of mecanum or Unicorn are well known in the CD community.

Their 3 degrees of freedom are translation forward/reverse, translation sideways, and rotation.

All possible motions or maneuvers can be commanded in terms of these 3 inputs.

To rotate while driving forward, for example, all that is required is a field-centric "forward" command (which gets converted into separate time-varying robot-centric forward/reverse and sideways commands) plus a rotate command.

The devil is in the details though. Unless the vehicle is built with craftsmanship and attention to detail, it will drift off course due to friction and motor performance tolerances. Encoders can be added to the gearboxes to provide closed-loop control of wheelspeed and/or position to help mitigate these variations, but doing so adds extra complexity and failure modes. For swerve especially, the interaction between steering angle and wheel speed requires careful design of the software to help the driver avoid sudden commands that could in some cases actually result in the vehicle tipping over. So that's the challenge, and it's one of the reasons why teams who want to try their hand at swerve do so off-season.

Looks like Team 973 has engineered and crafted a fine specimen. It will be fun to see it perform.

1 given a desired vehicle motion, convert that into the required 4 wheel speeds (for mecanum) or the required 4 wheelspeed/steeringAngle pairs (for swerve)



Tristan Lall 28-09-2011 17:16

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!)

AlecMataloni 28-09-2011 17:51

Re: pic: FRC973 Presents Emperor Swerve
 
It's absolutely gorgeous. Well done!

waialua359 28-09-2011 19:22

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

rsisk 28-09-2011 19:26

Re: pic: FRC973 Presents Emperor Swerve
 
Can someone explain in simple terms what you mean by translation and rotation?

EricH 28-09-2011 19:30

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by rsisk (Post 1079096)
Can someone explain in simple terms what you mean by translation and rotation?

Rotation: Turning about a single point, usually (but not always) the center of the robot, or somewhere close to that area.
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.

AdamHeard 28-09-2011 19:38

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:

Originally Posted by EricH (Post 1079097)
Rotation: Turning about a single point, usually (but not always) the center of the robot, or somewhere close to that area.
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.

The point of rotation is not a point we directly control, it is determined by the combination of x, y and rotation inputs. It is only ever on the robot when our translation speed is very slow or nonexistant (which I guess is true of all FRC robots).

Triple B 28-09-2011 21:13

Re: pic: FRC973 Presents Emperor Swerve
 
very nice
mike d

Ether 28-09-2011 21:19

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by rsisk (Post 1079096)
Can someone explain in simple terms what you mean by translation and rotation?

You pick a point, usually the center of geometry of the wheels1, and then any motion of the vehicle can be described in terms of these 3 "degrees of freedom":

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


Ankit S. 28-09-2011 21:21

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Emperor Swerve is a fully omnidirectional swerve that can translate and rotate simultaneously through all orientations.
How easy is it for you to do this? (how much driver input is required?)

I remember accomplishing this on our robot, but it was a very tough maneuver.

Andrew Lawrence 28-09-2011 21:22

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Ether (Post 1079129)
You pick a point, usually the center of geometry of the wheels1, and then any motion of the vehicle can be described in terms of these 3 "degrees of freedom":

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

It's funny. I learn more from Ether's posts than I do from my normal science class! Thank you, Ether, for your interesting yet educational posts! :D

AdamHeard 28-09-2011 21:24

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by BeltSanderRocks (Post 1079130)
How easy is it for you to do this? (how much driver input is required?)

I remember accomplishing this on our robot, but it was a very tough maneuver.

Without a gyro on there, it'd take some skill. With a gyro it's a trivial maneuver. You shift the coordinate inputs by the gyro's angle, it's known as "field-centric" drive. We don't plan to have the robot that way all match, just when the driver wants to spring down the field while doing high magnitude rotation.

akoscielski3 28-09-2011 22:01

Re: pic: FRC973 Presents Emperor Swerve
 
Is there a video of the robot performing yet? This looks really Awesome though!

Ether 28-09-2011 22:03

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by BeltSanderRocks (Post 1079130)
How easy is it for you to do this? (how much driver input is required?)

I remember accomplishing this on our robot, but it was a very tough maneuver.

Adam beat me to it, but I'll go ahead and post this in case it adds anything to the explanation.

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)

2) The computer takes this command, and uses the gyro reading to figure out what the "robot-centric" commands (fore/aft and port/starboard with respect to the robot) must be to accomplish the driver's desired motion.
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).




Jared Russell 29-09-2011 08:14

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

Ether 29-09-2011 11:27

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Jared341 (Post 1079213)
this is one of the common "gotchas" that makes swerve programming much, much more complicated than just implementing the inverse kinematics

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.



AdamHeard 29-09-2011 14:45

Re: pic: FRC973 Presents Emperor Swerve
 
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!).

Quote:

Originally Posted by Ether (Post 1079246)
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.



AdamHeard 03-10-2011 01:40

Re: pic: FRC973 Presents Emperor Swerve
 
We fixed the "weird electrical issues" and got it driving in much more responsive fashion.

If you try to read more than 4 encoders at 4x resolution, the remaining encoders will always repeat a zero value. After hours of debugging, seeing the encoders actually generate pulses, but not increment, we were going crazy. Austin on 254 tipped us off to the issue and we fixed it.

Video was taken, but it was on a tether cable. I promise we'll get good video this coming weekend when we drive with radios.

Gdeaver 03-10-2011 09:17

Re: pic: FRC973 Presents Emperor Swerve
 
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

apalrd 03-10-2011 09:26

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Gdeaver (Post 1079692)
...The C-rio only has 4 4x encoders. Why not save them for velocity needs?...

You realistically don't need 4x decoding on an encoder used for velocity. The cRio has 4 Encoder modules for 4x decoding, but it also has 8 Counter modules for 1x or 2x encoding (yes, the counter modules have direction through the B phase).

We ran our encoders at 1x for the entire season, doing full teleop speed control, without resolution issues (we did, however, find a bug in the FPGA code which calculates rate, and used the workaround of not using those encoder modules). We used 250 count AM encoders to 6" wheels (direct).

Although I do agree that, in general, absolute sensors are better for absolute positioning (such as a crab pod, elevator, arm, etc.)

Akash Rastogi 03-10-2011 09:28

Re: pic: FRC973 Presents Emperor Swerve
 
Adam what were the encoders you used? Link/part number?

Tom Bottiglieri 03-10-2011 11:08

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1079664)
We fixed the "weird electrical issues" and got it driving in much more responsive fashion.

If you try to read more than 4 encoders at 4x resolution, the remaining encoders will always repeat a zero value. After hours of debugging, seeing the encoders actually generate pulses, but not increment, we were going crazy. Austin on 254 tipped us off to the issue and we fixed it.

Video was taken, but it was on a tether cable. I promise we'll get good video this coming weekend when we drive with radios.

Ugh, don't get me started on encoders and the cRIO. We used a ton of encoders and it seems every combination you can think of using 4x, 2x, and 1x decoding would break something or other. I guess that's what happens when everything on the FPGA is a black box.

PHP Code:

A_ISR(){
   
+= (getB()) ? : -1;


All for 1,000th the price! Le sigh.

Gdeaver 03-10-2011 11:38

Re: pic: FRC973 Presents Emperor Swerve
 
There are digital SPI encoders available that reasonably priced.
http://products.cui.com/CUI_AMT203-V...df?fileID=3125
But then how good is the c-rio SPI implementation?

Joe Ross 03-10-2011 11:54

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1079664)
If you try to read more than 4 encoders at 4x resolution, the remaining encoders will always repeat a zero value. After hours of debugging, seeing the encoders actually generate pulses, but not increment, we were going crazy.

This is documented in the WPI Robotics Library User’s Guide. It looks like Java and LabVIEW give errors if more then four 4x encoders are allocated, but not C++.

Quote:

Originally Posted by Tom Bottiglieri (Post 1079707)
Ugh, don't get me started on encoders and the cRIO. We used a ton of encoders and it seems every combination you can think of using 4x, 2x, and 1x decoding would break something or other. I guess that's what happens when everything on the FPGA is a black box.

Did you have problems with anything other then the rate output? That was the only reported problem. That's been fixed in off-season updates for C++ and LabVIEW.

Quote:

Originally Posted by Gdeaver (Post 1079692)
The C-rio only has 4 4x encoders. Why not save them for velocity needs?

I recommend the opposite if you're using the FPGA's rate. With 4x encoding, you get more noise in the velocity due to quadrature phase errors in the encoder wheel. I recommend 1x for velocity and 4x for distance.

AdamHeard 03-10-2011 12:19

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Gdeaver (Post 1079692)
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.

Gdeaver 03-10-2011 12:46

Re: pic: FRC973 Presents Emperor Swerve
 
The encoder issue seems to have split in 2 directions. I was talking about using quadrature encoders to provide absolute position for the swerve steering. If I understand it right, the crio is configured with 8 counters. So if 4 4x encoders are used for swerve wheel absolute position then the counters are used up. I suggest that 4 analog voltage absolute encoders be used for wheel position and then the counters can be used for wheel velocity or distance and any other bot mechanism needs. On our bot we used 4 analog absolutes for steering and 1 for our arm. We just used a tachometer on the wheels so we have plenty of counters for future needs. My point was quadrature with index is not the best strategy for measuring wheel position for swerve.

Joe Ross 03-10-2011 12:50

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Gdeaver (Post 1079723)
The encoder issue seems to have split in 2 directions. I was talking about using quadrature encoders to provide absolute position for the swerve steering. If I understand it right, the crio is configured with 8 counters. So if 4 4x encoders are used for swerve wheel absolute position then the counters are used up.

The FPGA had four 4x encoders and 8 additional counters. You can have 4 4x encoders and 8 1x or 2x encoders.

AdamHeard 03-10-2011 12:59

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Gdeaver (Post 1079723)
The encoder issue seems to have split in 2 directions. I was talking about using quadrature encoders to provide absolute position for the swerve steering. If I understand it right, the crio is configured with 8 counters. So if 4 4x encoders are used for swerve wheel absolute position then the counters are used up. I suggest that 4 analog voltage absolute encoders be used for wheel position and then the counters can be used for wheel velocity or distance and any other bot mechanism needs. On our bot we used 4 analog absolutes for steering and 1 for our arm. We just used a tachometer on the wheels so we have plenty of counters for future needs. My point was quadrature with index is not the best strategy for measuring wheel position for swerve.

We are using the quadrature encoders for wheel steering. This is for the reasons I stated above (Never having to zero sensors is a really big deal to us). You'll also notice most industrial applications use an encoder + zero of sorts over analog sensors.

We also aren't measuring wheel speed at all. Instead we opted to put a pair of follower wheels (oriented x-y obviously) and a gyro for all position and velocity calculations.

Ether 03-10-2011 13:36

Re: pic: FRC973 Presents Emperor Swerve
 

Question for those teams who have incorporated wheel speed reversal (for better steering response) into their swerve control software: what inputs and thresholds did you use?

For example, what steering angle threshold did you use to enable wheelSpeed reversal? 90 degrees, or something greater? (and was this determined empirically or by analysis). And, did you factor the wheelSpeed process variable into that decision? (i.e the angle threshold varies with the wheel speed).

Also, did you look at what the other wheels are doing, was each wheel controlled independently?


AdamHeard 03-10-2011 13:41

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Ether (Post 1079732)

Question for those teams who have incorporated wheel speed reversal (for better steering response) into their swerve control software: what inputs and thresholds did you use?

For example, what steering angle threshold did you use to enable wheelSpeed reversal? 90 degrees, or something greater? (and was this determined empirically or by analysis). And, did you factor the wheelSpeed process variable into that decision? (i.e the angle threshold varies with the wheel speed).

Also, did you look at what the other wheels are doing, was each wheel controlled independently?

Currently it's right at 90 degrees and all four wheels are independant.

We plan to test and tweak up until season, we have discussed the following;
-Changing angle for determination of "shortest path" based on current steering speed (as you really want the fastest path, not the shortest path).
-Generating steering paths as a function of all 4 wheels to ensure they always place nice.
-Some sort of filtering and prediction on the inputs from the joysticks to save slight amounts of time in steering (being able to determine if the driver is going all the way to the other side, or merely returning to center, etc...).
-Recording all variables, inputs and outputs for the entire drivetrain and graphing overtime to better understand what is happening.

We chose to steer with window motors are they are the worst motors in the kit, we knew it'd be trivial to change to other motors for season and the windows would force us to truly optimize the code to make the system as responsive as possible (like I've said before, I want a driver from our team, 254, 330, 1538, etc. able to drive it without complaining about the lag time. These are all teams that usually go with very fast and responsive 6wds here on the west coast).

Mark Sheridan 29-10-2011 19:31

Re: pic: FRC973 Presents Emperor Swerve
 
Any recent developments with Emperor Swerve? I hope you can post at close-up pictures of the swerve modules. I am dying to see it in detail.

Katie_UPS 29-10-2011 21:10

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1079716)
Lots of questions here.

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

Is there a way to see the code as well (now that this thread is revived and I'm curious)?

AdamHeard 29-10-2011 21:38

Re: pic: FRC973 Presents Emperor Swerve
 
We've been really busy with a lot of projects, training, and new students. So we've only slowly been working on it. We're putting in a longhaul session on it tomorrow.

We really just need a lot of drive practice on it at this point to prepare us for the tournament in two weeks.

As for posting Code, do you mean just the field-centric code or all of the code?

CAD will be posted along with a reveal video, etc... after our event in two weeks.

Peyton Yeung 29-10-2011 21:51

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1083198)
CAD will be posted along with a reveal video, etc... after our event in two weeks.

Oh the humanity...I've been waiting for a month to see your guy's video...guess I can wait 2 more weeks :yikes:

AdamHeard 29-10-2011 21:57

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Tubatroopa (Post 1083201)
Oh the humanity...I've been waiting for a month to see your guy's video...guess I can wait 2 more weeks :yikes:

We're sorry to let everyone down, we've just been SO busy with so many different things going on. We haven't filmed anything good enough to post.

Peyton Yeung 29-10-2011 22:12

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1083202)
We're sorry to let everyone down, we've just been SO busy with so many different things going on. We haven't filmed anything good enough to post.

No it's fine :yikes: It just means your bot will be so much more super when it is done

thefro526 29-10-2011 23:09

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1083202)
We're sorry to let everyone down, we've just been SO busy with so many different things going on. We haven't filmed anything good enough to post.

Adam, If I may make a request here, can you post a sort of 'evolution of the swerve driver' video? A highlight reel doesn't really do much good to a team who has never done a swerve before. It'd be much more beneficial to see a 'this is how we were and this is how we are 2 weeks later video' - or at least that's what would help me.

Akash Rastogi 29-10-2011 23:50

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by thefro526 (Post 1083206)
Adam, If I may make a request here, can you post a sort of 'evolution of the swerve driver' video? A highlight reel doesn't really do much good to a team who has never done a swerve before. It'd be much more beneficial to see a 'this is how we were and this is how we are 2 weeks later video' - or at least that's what would help me.

Along those lines, do you have some sort of journal of your design iterations? This would be really cool to see.

AdamHeard 30-10-2011 01:08

Re: pic: FRC973 Presents Emperor Swerve
 
We can't really do such a video, as very little iteration has happened since the vehicle has been built (and it's all been in software).

All the iteration happened when we were drawing in Solidworks. We sort of "got it right the first time" in terms of this design. This is only because we had previously made and extensively drove our previous crab drive, have been kicking around ideas for a repeat of it for years, and talked with everyone we could on other teams that had experience with crab drives as we were designing.

A highlight video and the CAD files are about the best we can do, we've got a lot going on right now.

Chris is me 30-10-2011 13:31

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1083212)
A highlight video and the CAD files are about the best we can do, we've got a lot going on right now.

What, "only" a video and CAD? Geez, how secretive of you. :)

In all seriousness, the only thing that inspires me more than the technical achievements of this robot is your team's willingness to share it with the world.

AdamHeard 15-11-2011 13:26

Re: pic: FRC973 Presents Emperor Swerve
 
Just added the CAD to our paper with all our robots. Check it out!

Some details are missing, and a few things got messed up during the .stp conversion, but the good stuff is all there.

Peyton Yeung 15-11-2011 19:05

Re: pic: FRC973 Presents Emperor Swerve
 
It's so beautiful!!!! Well done :)

Andrew Lawrence 15-11-2011 20:25

Re: pic: FRC973 Presents Emperor Swerve
 
Video soon? :D

AustinSchuh 15-11-2011 23:51

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by SuperNerd256 (Post 1085246)
Video soon? :D

Go watch the finals from the Throwdown. I believe that they are posted in one of the other threads.

Joe Ross 16-11-2011 00:10

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AustinSchuh (Post 1085288)
Go watch the finals from the Throwdown. I believe that they are posted in one of the other threads.

The 971 centric camera only shows about 10 seconds of 973 moving over 3 matches.

R.C. 16-11-2011 00:16

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by Joe Ross (Post 1085290)
The 971 centric camera only shows about 10 seconds of 973 moving over 3 matches.

Joe I believe Justin tv keeps an archive of all the matches. We'll be putting up the archive we have soon!

-RC

Eugene Fang 16-11-2011 01:40

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by R.C. (Post 1085291)
Joe I believe Justin tv keeps an archive of all the matches. We'll be putting up the archive we have soon!

-RC

The matches are indeed archived on Justin.tv for a week or so.

http://www.justin.tv/madtownthrowdown/videos

AdamHeard 16-11-2011 13:58

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by EugeneF (Post 1085294)
The matches are indeed archived on Justin.tv for a week or so.

http://www.justin.tv/madtownthrowdown/videos

Is that all of quals and elims?

Eugene Fang 16-11-2011 14:11

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by AdamHeard (Post 1085343)
Is that all of quals and elims?

It should be. It's kinda disorganized in terms of where the video is split though. =\

Edit: Actually there doesn't seem to be enough time to include all quals and elims... I have the raw archives I'll see if I can get them up somewhere.

sanddrag 20-10-2012 23:34

Re: pic: FRC973 Presents Emperor Swerve
 
Hey Adam,

Thanks for making the CAD available. I have a couple questions after looking at the CAD.

1. It looks like the window motor plug intersects/conflicts with the coaxial tube. How is it in real life?

2. How did you address the issue of backlash/slop in the window motors?

3. Are there any issues with the midline of the wheel not being at the axis of rotation?

Thanks.

AdamHeard 22-10-2012 13:06

Re: pic: FRC973 Presents Emperor Swerve
 
Quote:

Originally Posted by sanddrag (Post 1191128)
Hey Adam,

Thanks for making the CAD available. I have a couple questions after looking at the CAD.

1. It looks like the window motor plug intersects/conflicts with the coaxial tube. How is it in real life?

2. How did you address the issue of backlash/slop in the window motors?

3. Are there any issues with the midline of the wheel not being at the axis of rotation?

Thanks.

1) We cut the window motor connector off and soldered to the exposed leads.

2) There was little backlash between sensor and wheel, so the control loop handles this somewhat. Swerve is much less about precise straight and much more about continuous fluid motion. that being said, I drove 1717's 2011 bot (not same layout, but same steering gearing as their 2012 give or take) and the steering felt way more responsive. Our robot responded well, but it was a bit fuzzy compare to theirs in that regard. I bet their drivers felt like they had a bit better precise control. That's the difference between 500 series motors and a window motor though.

3) None that we noticed, it makes packaging a lot nicer.



Swerve was an awesome learning experience for us, but we will not be doing it again for season. Our team is very small, but have lots of resources and work hard (that's how we got those resources). Even with that though, we feel we'd field a more competitive simpler robot.

We'll let 1717 keep it going.


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