Go to Post The possibilities for zip ties are endless. - Elgin Clock [more]
Home
Go Back   Chief Delphi > ChiefDelphi.com Website > Extra Discussion
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rating: Thread Rating: 3 votes, 5.00 average. Display Modes
  #46   Spotlight this post!  
Unread 29-09-2011, 14:45
AdamHeard's Avatar
AdamHeard AdamHeard is offline
Lead Mentor
FRC #0973 (Greybots)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2004
Location: Atascadero
Posts: 5,508
AdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond repute
Send a message via AIM to AdamHeard
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 View Post
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.

Reply With Quote
  #47   Spotlight this post!  
Unread 03-10-2011, 01:40
AdamHeard's Avatar
AdamHeard AdamHeard is offline
Lead Mentor
FRC #0973 (Greybots)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2004
Location: Atascadero
Posts: 5,508
AdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond repute
Send a message via AIM to AdamHeard
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.
Reply With Quote
  #48   Spotlight this post!  
Unread 03-10-2011, 09:17
Gdeaver Gdeaver is offline
Registered User
FRC #1640
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 2001
Location: West Chester, Pa.
Posts: 1,367
Gdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond repute
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
Reply With Quote
  #49   Spotlight this post!  
Unread 03-10-2011, 09:26
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: pic: FRC973 Presents Emperor Swerve

Quote:
Originally Posted by Gdeaver View Post
...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.)
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
Reply With Quote
  #50   Spotlight this post!  
Unread 03-10-2011, 09:28
Akash Rastogi Akash Rastogi is offline
Jim Zondag is my Spirit Animal
FRC #2170 (Titanium Tomahawks)
Team Role: Mentor
 
Join Date: Feb 2007
Rookie Year: 2006
Location: Manchester, Connecticut
Posts: 7,003
Akash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond reputeAkash Rastogi has a reputation beyond repute
Re: pic: FRC973 Presents Emperor Swerve

Adam what were the encoders you used? Link/part number?
__________________
My posts and opinions do not necessarily reflect those of my affiliated team.
['16-'xx]: Mentor FRC 2170 | ['11-'13]: Co-Founder/Mentor FRC 3929 | ['06-'10]: Student FRC 11 - MORT | ['08-'12]: Founder - EWCP (OG)

Last edited by Akash Rastogi : 03-10-2011 at 09:32.
Reply With Quote
  #51   Spotlight this post!  
Unread 03-10-2011, 11:08
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,187
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: pic: FRC973 Presents Emperor Swerve

Quote:
Originally Posted by AdamHeard View Post
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.

Last edited by Tom Bottiglieri : 03-10-2011 at 11:11.
Reply With Quote
  #52   Spotlight this post!  
Unread 03-10-2011, 11:38
Gdeaver Gdeaver is offline
Registered User
FRC #1640
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 2001
Location: West Chester, Pa.
Posts: 1,367
Gdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond repute
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?
Reply With Quote
  #53   Spotlight this post!  
Unread 03-10-2011, 11:54
Joe Ross's Avatar Unsung FIRST Hero
Joe Ross Joe Ross is offline
Registered User
FRC #0330 (Beachbots)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1997
Location: Los Angeles, CA
Posts: 8,574
Joe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond repute
Re: pic: FRC973 Presents Emperor Swerve

Quote:
Originally Posted by AdamHeard View Post
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 View Post
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 View Post
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.
Reply With Quote
  #54   Spotlight this post!  
Unread 03-10-2011, 12:19
AdamHeard's Avatar
AdamHeard AdamHeard is offline
Lead Mentor
FRC #0973 (Greybots)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2004
Location: Atascadero
Posts: 5,508
AdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond repute
Send a message via AIM to AdamHeard
Re: pic: FRC973 Presents Emperor Swerve

Quote:
Originally Posted by Gdeaver View Post
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.
Reply With Quote
  #55   Spotlight this post!  
Unread 03-10-2011, 12:46
Gdeaver Gdeaver is offline
Registered User
FRC #1640
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 2001
Location: West Chester, Pa.
Posts: 1,367
Gdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond repute
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.
Reply With Quote
  #56   Spotlight this post!  
Unread 03-10-2011, 12:50
Joe Ross's Avatar Unsung FIRST Hero
Joe Ross Joe Ross is offline
Registered User
FRC #0330 (Beachbots)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1997
Location: Los Angeles, CA
Posts: 8,574
Joe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond repute
Re: pic: FRC973 Presents Emperor Swerve

Quote:
Originally Posted by Gdeaver View Post
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.
Reply With Quote
  #57   Spotlight this post!  
Unread 03-10-2011, 12:59
AdamHeard's Avatar
AdamHeard AdamHeard is offline
Lead Mentor
FRC #0973 (Greybots)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2004
Location: Atascadero
Posts: 5,508
AdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond repute
Send a message via AIM to AdamHeard
Re: pic: FRC973 Presents Emperor Swerve

Quote:
Originally Posted by Gdeaver View Post
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.

Last edited by AdamHeard : 03-10-2011 at 13:10.
Reply With Quote
  #58   Spotlight this post!  
Unread 03-10-2011, 13:36
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,097
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
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?

Reply With Quote
  #59   Spotlight this post!  
Unread 03-10-2011, 13:41
AdamHeard's Avatar
AdamHeard AdamHeard is offline
Lead Mentor
FRC #0973 (Greybots)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2004
Location: Atascadero
Posts: 5,508
AdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond reputeAdamHeard has a reputation beyond repute
Send a message via AIM to AdamHeard
Re: pic: FRC973 Presents Emperor Swerve

Quote:
Originally Posted by Ether View Post

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

Last edited by AdamHeard : 03-10-2011 at 13:44.
Reply With Quote
  #60   Spotlight this post!  
Unread 29-10-2011, 19:31
Mark Sheridan's Avatar
Mark Sheridan Mark Sheridan is offline
Head Mentor
FRC #3476 (Code Orange)
Team Role: Mentor
 
Join Date: Mar 2010
Rookie Year: 2002
Location: Irvine, CA
Posts: 560
Mark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond reputeMark Sheridan has a reputation beyond repute
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.
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 01:02.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi