Chief Delphi

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)

LondonBoy29 14-12-2011 16:54
WCD vs. Swerve
 
This year in preseason robotics, we are experimenting with both a WCD and a swerve chassis to prepare for the season. I am leading a grouping making the WCD. People always call WCD a back-up drive, but then I point out to them that most teams in Einstein in a given year use it (or a modified form of the 6 wheel drive). Can somebody please elaborate on why you would want to use WCD over swerve in a game that requires maneuverability (such as 2008 or 2011)? Thanks :)

Andrew Lawrence 14-12-2011 17:07
Re: WCD vs. Swerve
 
WCDs are a lot lighter than swerves, and for the most part are a lot simpler. It's easier to program a WCD, also. This extra time and unused weight can be used for other things.

Mk.32 14-12-2011 17:17
Re: WCD vs. Swerve
 
Having recently CADed and priced out both a WCD and a Swerve build. Our team is planning on building a WCD drive for it's final off season project.

The WCD is a lot simpler and cheaper compared to the swerve.
With a WCD you can probably get a drive base done within the first week of build season, with a swerve and even if you prototype it over off season it would probably take longer depending on how fast your machining turn around is. With a limited amount of abilities I would rather focus on building manipulators and testing them, then on drive.

Alex.q 14-12-2011 17:23
Re: WCD vs. Swerve
 
It takes a lot of time, resources, and expertise to make a good swerve drive. There are also more opportunities for things to go wrong with a swerve, so it can be less reliable. I would not recommend using a swerve drive unless you can see a huge advantage in the game by having it that would offset all of these disadvantages. (My team is in the same boat, we prototyped a swerve and a 6wd).

Jim Wilks 14-12-2011 17:30
Re: WCD vs. Swerve
 
A few years back, our team built a swerve during build season. We had prototyped one as an offseason event, so we thought all would go well. It did not. It ended up as the biggest single build mistake our team has ever made.

O'Sancheski 14-12-2011 17:36
Re: WCD vs. Swerve
 
As everyone has already stated, Swerves take more resources and time. A 6WD WCD in my opinion is better. Swerve might look cool and perform a little better than a WCD, but there are a few reasons that I would not go with a swerve for next season.

1. We have no idea what the game is. Swerve Drive might not be necessary. I'm still not entirely convinced it was necessary for Logomotion.
2. Cost factor. A 6WD WCD is significantly cheaper than a swerve, even if you custom make your swerve drive. (i.e. not use the wildswerve or 221 Swerve Drive Systems.)
3. Takes a lot more time and knowledge to program a swerve. Unless you have a complete team of Wildstang, Trinity, Winnovation, or D'Penguineers programmers, it will take a significantly longer time to program it in the build season.
4. Lastly, Swerve Drive robots are significantly harder to drive than a standard 6WD. Having omnidirectional movement at your fingertips whenever you want can be a little intimidating. Whether it's Coaxle Swerve or Unicorn Drive, it doesn't make any difference. It takes a huge learning curve to properly learn how to drive a swerve.

This is just my $0.02, but I would like to see what others say about this. I think Swerve Drive is awesome. But if I was going to chose to go with swerve, I would take an extensive period of time to make sure I can create the perfect drivetrain for the next season.

Ninja_Bait 14-12-2011 17:48
Re: WCD vs. Swerve
 
Wow, sounds like everyone's prototyping a WCD and a swerve this year. Thought we were the only ones! Anyway, we too ended up only building the WCD. It's way simpler, cheaper, and easier to build. Even if we had built the swerve drive, we'd have never used it this year because of the complex programming and likely engineering issues that would have cropped up. We may use the WCD, though.

Also remember that good drivers trump good robots. Not only is it easier to drive a WCD, but the shortened build schedule affords you more practice time.

Swerve drive IS awesome, but only if you've perfected it. It sucks when it doesn't work or doesn't drive or doesn't fit in budget.

Cory 14-12-2011 18:02
Re: WCD vs. Swerve
 
Quote:
Originally Posted by O'Sancheski (Post 1091187)
1. We have no idea what the game is. Swerve Drive might not be necessary. I'm still not entirely convinced it was necessary for Logomotion.
I know what you mean, but swerve drive is NEVER necessary.

AdamHeard 14-12-2011 18:21
Re: WCD vs. Swerve
 
Swerves require good code, and a lot of it to really use their performance as an advantage. A lot of tweaking, testing, and practice as well.

6wd's require no special code, and don'y rely on sensors at all.

Half your robot could be broken, some drive chains snapped, a drive motor burned out, etc... and your WCD will still be trucking.

Chexposito 14-12-2011 18:37
Re: WCD vs. Swerve
 
i have only seen one successful swerve drive. that drive was done by bomb squad (16) and they have been working on that drive for years. we have had some mildly successful attempts, but nothing has worked as well as theirs. also looking at the type of drive train on Einstein, you'll notice a skid like west coast is there a lot more

EricH 14-12-2011 18:53
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Chexposito (Post 1091205)
i have only seen one successful swerve drive. that drive was done by bomb squad (16) and they have been working on that drive for years. we have had some mildly successful attempts, but nothing has worked as well as theirs. also looking at the type of drive train on Einstein, you'll notice a skid like west coast is there a lot more
111 (2003 National Champions). 118, back around 2005-2007, had a few solid ones. 1717 hasn't won a championship division yet, but they have a pretty potent swerve.

AlecMataloni 14-12-2011 18:56
Re: WCD vs. Swerve
 
Quote:
Originally Posted by EricH (Post 1091213)
111 (2003 National Champions). 118, back around 2005-2007, had a few solid ones. 1717 hasn't won a championship division yet, but they have a pretty potent swerve.
Wasn't 67 a swerve in 2005?

Also, we were swerve in '09 as well.

EricH 14-12-2011 18:57
Re: WCD vs. Swerve
 
Quote:
Originally Posted by AlecMataloni (Post 1091215)
Wasn't 67 a swerve in 2005?

Also, we were swerve in '09 as well.
I can never remember for sure if 67 was a swerve or omni in '05. I'm pretty sure they had a 3-wheel swerve, though.

AdamHeard 14-12-2011 19:41
Re: WCD vs. Swerve
 
Quote:
Originally Posted by EricH (Post 1091217)
I can never remember for sure if 67 was a swerve or omni in '05. I'm pretty sure they had a 3-wheel swerve, though.
Swerve for sure.

Chexposito 14-12-2011 22:48
Re: WCD vs. Swerve
 
my point is that they are the only team that consistently uses it and seems to have come close to, if not perfected it.

Andrew Lawrence 14-12-2011 22:57
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Chexposito (Post 1091289)
my point is that they are the only team that consistently uses it and seems to have come close to, if not perfected it.
I wouldn't say they've perfected it, but 973's swerve is one of the best swerves I've seen in my days, and I've seen a lot of swerves.

AlecMataloni 14-12-2011 22:58
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Chexposito (Post 1091289)
my point is that they are the only team that consistently uses it and seems to have come close to, if not perfected it.
Well then, I respectfully disagree.

EricH 14-12-2011 23:00
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Chexposito (Post 1091289)
my point is that they are the only team that consistently uses it and seems to have come close to, if not perfected it.
No, they aren't.

111. 1 National Championship on swerve drive. Uses it fairly often when the game calls for it.
118. 2-3 years with what was then one of the ultimate swerve drives.
67. 1 World Championship on swerve drive.
148. See 67.
1717. Consistently uses swerve.

973 developed a Unicorn drive (Emperor Swerve) this offseason that could rival some of these others. They have yet to use it in the regular season.

16 is NOT the only team that has come close to perfecting swerve, or that consistently uses it. While they do consistently use a very good one, saying that they are the only one displays ignorance. Continuing to say that they are the only one after other teams in the same category have been brought to one's attention displays willful ignorance.

Use of swerve without proper engineering analysis to determine that it is the best option, or close to it, is a very risky proposition at best, and a waste of resources at worst.

Andrew Schreiber 14-12-2011 23:52
Re: WCD vs. Swerve
 
Quote:
Originally Posted by EricH (Post 1091295)
No, they aren't.

111. 1 National Championship on swerve drive. Uses it fairly often when the game calls for it.
118. 2-3 years with what was then one of the ultimate swerve drives.
67. 1 World Championship on swerve drive.
148. See 67.
1717. Consistently uses swerve.

973 developed a Unicorn drive (Emperor Swerve) this offseason that could rival some of these others. They have yet to use it in the regular season.

16 is NOT the only team that has come close to perfecting swerve, or that consistently uses it. While they do consistently use a very good one, saying that they are the only one displays ignorance. Continuing to say that they are the only one after other teams in the same category have been brought to one's attention displays willful ignorance.

Use of swerve without proper engineering analysis to determine that it is the best option, or close to it, is a very risky proposition at best, and a waste of resources at worst.
You forgot a pretty major team that has used swerve quite a few times since their latest World Championship (my gut says every year). Though they haven't been quite the BEAST they have been in the past they still beatty out most teams for always managing to find a way to win. I speak of course of Team Hammond for those of you who hadn't figured it out.

Also, 469 used swerve for a couple years (07/08) with reasonable success.

MichaelBick 15-12-2011 00:23
Re: WCD vs. Swerve
 
If you look at videos of 1717, you will see how smooth and perfected their drivetrain has become. They consistently use it, and it shows, how while not being necessary, swerve helps so much in scoring. Of course, this relies on the fact that swerve is built and programmed right.

Cory 15-12-2011 01:49
Re: WCD vs. Swerve
 
111 is swerve as far as I'm concerned.

I don't mean that as a sleight to 16, 47, 118, etc. If I think of swerve I think of 111 and then everyone else.

Aren_Hill 15-12-2011 02:00
Re: WCD vs. Swerve
 
A lot of people posting without first hand knowledge, that's fun.

Adam and 973 are in the best position to answer the original question, as they've had quite a few 6wd cantilevered drivetrains and have recently given swerve a try.

My recommendations is know what you're getting into, easiest way to do that is have a fully functional prototype you can drive the wheels off of. I agree with Adam that the programming/control aspect is what makes a swerve great, I've seen many swerves (ours included), with control not quite what it should've been. As a result many of the Pro's were diminished and the effectiveness brought below that of a normal 6wd or 8wd in some cases.

Garrett.d.w 15-12-2011 02:10
Re: WCD vs. Swerve
 
Last year the Pigmice built a swerve drive (but like idiots we didn't prototype it in the offseason). Everything that we did worked, and we had no issues until it came to driving.
Because we hadn't prototyped it in the off season no one had ever driven it extensively. We wound up modifying it in the pits to drive like a tank (two sets of omni wheels in the front pods). This made the robot easy to drive, and because the swerve cababilities were left intact, we had fun watching people's faces when we could simply strafe around them.

Moral of the story, don't build it if you don't know how to use it to it's full potential. Our scoring during regionals would have been nearly identical if we had gone WCD.

Oh, and its cool, but very rarely necessary. If you have the time and the money, try it, but drive it into the ground in the off season before you decide to compete with it.

Peter Matteson 15-12-2011 07:41
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Aren_Hill (Post 1091325)
A lot of people posting without first hand knowledge, that's fun.

Adam and 973 are in the best position to answer the original question, as they've had quite a few 6wd cantilevered drivetrains and have recently given swerve a try.
Excellent point.

Listen to the the EWCP podcast from November 27th where they discuss in depth what 973 went through and thought of when they built their swerve and their experience driving both. It's fun to hear people discuss their first hand account.

Now to my opinion: If you don't have a drivable fully working swerve built in the offseason (offseason is really over so I mean today) you will probably not be ready this season. If you can't drive you can't do anything. The time it will take to get the drive up and running in the build season will submarine most of the stuff you're working on. In my experience when driving is a forgone conclusion you can focus better on accomplishing the game task, scoring points. I use the kit bot as an example of this. Prior to the 2005 intro of the 1st kitbot you were very lucky if your partners could drive during quals sometimes and fewer teams could accomplish difficult tasks because the whole build season was spent getting the ability to drive. End opinion.

Jared Russell 15-12-2011 08:03
Re: WCD vs. Swerve
 
Quote:
Originally Posted by EricH (Post 1091295)
111. 1 National Championship on swerve drive. Uses it fairly often when the game calls for it.
2 National Championships. 2003 and 2009.

Gdeaver 15-12-2011 08:07
Re: WCD vs. Swerve
 
1640 has done 4 wheel independent drive, independent steering the last two years. We have the weight of each module down to 9 LBS. We have the durability nailed too. Greater that 100 hours on both bots. We have put an enormous amount of time, effort and money into swerve drive. Most teams may be stressed beyond their limits to perfect a swerve drive. With swerve you basically have to have every thing perfect or things will go very bad. The risk of failure with taking on swerve would lead me to recommend that most teams forget swerve and work on perfecting a 6 wheel drive base and focus more time on other aspects of the robot. We still do not have the swerve where we want it. We need to work on the driver presentation. I will say that with this years swerve and a trained driver, swerve can be a real competitive advantage. Is it worth the effort and money. We debate this issue constantly. If you don't have a functioning swerve drive base right now then it's a no brainer, do a 6 wheel for 2012.

Ether 15-12-2011 08:37
Re: WCD vs. Swerve
 

Quote:
Originally Posted by Gdeaver (Post 1091360)
We still do not have the swerve where we want it. We need to work on the driver presentation
What is it about the driver interface that you need to work on?

Brandon Holley 15-12-2011 09:22
Re: WCD vs. Swerve
 
Piggy-backing on what Aren said- listen to some teams who have done a swerve before, and really try to understand the effort that was put into it.

For every 16, 111 or 118, there's got to be at least a dozen failed swerve drives. I say "failed" in the sense that they did not perform at those levels. The best swerve drives have tons of iteration in them. Obviously at some point you will have to commit to putting one on the field, but now-a-days with the kit bot and the larger knowledge base, almost anyone has a strong drivetrain on the field.

We have a couple iterations of swerve drive under our belt in the off-season, but we've still yet to implement it due to a number of reasons. I wouldn't even dream of trying to conjure a swerve for the 1st time in-season. There tends to be a ton of effort that many people overlook when they make the decision to pursue one. Make sure you are making a decision based on your resources, and your abilities.

-Brando

Ether 15-12-2011 09:39
Re: WCD vs. Swerve
 

Quote:
Originally Posted by Brandon Holley (Post 1091375)
We have a couple iterations of swerve drive under our belt in the off-season, but we've still yet to implement it due to a number of reasons.
Brandon, could you elaborate a little on some of those reasons?

Brandon Holley 15-12-2011 09:57
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1091379)



Brandon, could you elaborate a little on some of those reasons?
Sure-

-We are probably at a spot now where mechanically we would feel comfortable with the system, however the first couple of tries definitely required some improvements before being implemented on the field.

-Part of those mechanical improvements were getting the weight down. We were at a decent spot weight wise with our initial design, but have been unable to get much more weight out of it. We're considering much different and new designs which would help with that, but then the mechanical iteration kind of goes backwards a little bit.

-Probably the biggest factor is the software development effort. We are just not at the point where the swerve is performing how we want it to. It requires a ton of driver practice to reach a level of performance that can be matched with just a small amount of practice on a 6WD or 8WD. We want to develop as intuitive a system as possible.

To go along with this, due to the nature of the mentors on our team (mainly college students), the engineering support is constantly in flux. While always solid, its ever changing. We really need someone to make this project their baby and help guide it to completion. We have unfortunately been unable to do that. Knowing it will probably take a couple of seasons to get right, we want to make sure we have a steady foundation before we start building on it.

-The last major factor has probably been timing. In 2010, we built a robot that very few teams attempted to build. Like 469, we were designed to recycle balls from the roll-in ramp by rolling them down our robot, off the bump, and into the goal. Being way to overly ambitious, we wanted to do all of this while hanging from the bar. Due to a number of reasons, the robot worked, but never as well as we wanted it to, or near the level of 469.

Going into last season we didn't want to have another "down" year, so we tried to play it "safe". If we went the swerve, and didn't get desirable results we would've had back to back seasons where our ambition got in the way of our success. We had an extremely successful year last year, so I believe the decision was right.

It is yet to be seen what will happen this upcoming season, but hopefully that gives you a window into some of our decision making.

JamesTerm 18-12-2011 19:43
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Gdeaver (Post 1091360)
1640 has done 4 wheel independent drive, independent steering the last two years. We have the weight of each module down to 9 LBS. We have the durability nailed too. We need to work on the driver presentation.
What you guys have done is exactly what I REALLY wish for our Team to try and pursue! Most-likely not this year, and perhaps not even in 2013...

I am going to approach this a bit differently... where the driver presentation is the very first thing we are going to get nailed down... if it cannot feel exactly like I want it then we shouldn't bother making it. In short I submit an idea that most people will not believe... here it is... I believe you can make it feel like a tank arcade drive (or even tank steering), with strafe.

There is one other idea I want to throw out... and that is the fear of failure hurts new innovation. I am prepared for the risk of failure with this driver presentation and I am not afraid... I know it is something I MUST pursue... it is like a calling that I cannot ignore.

Ether 18-12-2011 19:48
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1092082)
I submit an idea that most people will not believe... here it is... I believe you can make it feel like a tank arcade drive (or even tank steering), with strafe.
I'm curious why you think most people will not believe this.

O'Sancheski 18-12-2011 19:52
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092086)
I'm curious why you think most people will not believe this.
Same here.

I have seen swerve perform just like a tank drive. It's kind of pointless in my mind. But definitely possible.

JamesTerm 18-12-2011 20:08
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092086)
I'm curious why you think most people will not believe this.
There is much more to the idea that I cannot seem to put into words... for now I'll step down and get to work on it, and perhaps post a simulation demonstation sometime this summer. I really want to make sure this can work before I say too much. I guess for now let's just say I am talking to myself about believing this can be done. :)

JamesTerm 18-12-2011 20:14
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1092093)
There is much more to the idea that I cannot seem to put into words...
Ok I got to thinking... here is a game I've been working on since 2007... it can hopefully convey the idea I am talking about.

http://www.termstech.com/files/TheFr...CarpetRide.wmv

In short... we spend many hours to make sure the Joystick to control the ship is as easy to use as the mouse.

Ether 18-12-2011 20:32
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1092093)
There is much more to the idea that I cannot seem to put into words...
It would be good practice to try.

An inability to communicate your ideas effectively is a handicap you would be well served to strive to overcome.

JamesTerm 18-12-2011 20:46
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092117)
It would be good practice to try.
An inability to communicate your ideas effectively is a handicap you would be well served to strive to overcome.
Agreed... but not today. I need some time to prepare.

Gdeaver 18-12-2011 21:17
Re: WCD vs. Swerve
 
Driver presentation. May be some who have actually driven a swerve will comment. We have a 4 wheel drive 4 wheel steering bot. We have used a x-box and 2 kop joy sticks. Also, we tried a joystick with twist but, the drivers hatted the twist for chassis orientation. So how do you control the 4 degrees of freedom required for swerve driving. X, Y, Chassis orientation, and velocity.
We have always used the left joy stick for x-y and extrapolate velocity from it. The right joy stick x mixes in chassis rotation. This is what the programers and drivers ended up with. I feel that after watching our driving the last 2 years there is a major problem with this choice. Our drivers can make the bot dance on our practice field with no pressure. Under pressure at a comp I see the driving deteriorate. I believe their left hand or thumb coordination is being overloaded. What have other teams used. I believe the extrapolated velocity is the problem. For a short time in the 2010 off season we had the X - Y on the left X-box controller joy stick. Velocity on the right joystick x and chassis orientation on the analog triggers. I liked it. The programmer graduated and the code disappeared. We went back to the above described method. So what is the best driver presentation. Arguments welcomed.

JamesTerm 18-12-2011 23:50
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Gdeaver (Post 1092131)
So what is the best driver presentation. Arguments welcomed.
I think the most important design decision is to fundementally separate control and implementation in such a way where it becomes trivial to switch things around for trial and error. Also make it where there is a desired movement lead what is physically possible. I have solved these problems already where I fundementally work with a 2D vec of desired velocity and a float for heading. I have a class that figures out how to make that work. With this approach I can achieve the feel (e.g. elastic bell curve on rotation) of what the ships do in the game demo link I sent.

Me personally I think one arcade drive joystick just like tank with some strafe buttons elsewhere... but I want to customize to what the driver wishes.

JamesTerm 20-12-2011 10:46
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092117)
It would be good practice to try.
An inability to communicate your ideas effectively is a handicap you would be well served to strive to overcome.

Ok I will take a stab at this today... with a question. What makes a swerve drive so hard to drive vs. what makes a WCD easy to drive (both tank steering and arcade configurations)?

Ether 20-12-2011 12:01
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1092494)
Ok I will take a stab at this today... with a question. What makes a swerve drive so hard to drive vs. what makes a WCD easy to drive (both tank steering and arcade configurations)?
I will assume that, in this context, by "tank steering" a swerve you are referring to the driver interface (e.g. using Y axis of left and right joysticks) and not to the inverse kinematics used (i.e. not skid-steer).

Instead I assume you mean something like this:

FWD = (YL+YR)/2

RCW = (YL-YR)/2

STR = 0

... where YL and YR are the (inverted) joystick commands, and FWD, RCW, and STR are as defined here.

In that case, I will answer your question with a question: is a swerve with that driver interface "so hard to drive" ?

JamesTerm 20-12-2011 13:47
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092511)
In that case, I will answer your question with a question: is a swerve with that driver interface "so hard to drive" ?
Thanks so much for that link! That is half the problem I was trying to figure out. The other half will be the reverse of that where given the wheel angles and speeds, what is the current x, y and rotational (i.e. angular) velocities.

For now let's ditch the tank steering 2 joysticks except to say that it can be done. I think FWD and RCW can be on one joystick where left and right perform the rotation (I believe this is called arcade drive)... Just this much is what we had this season on a WCD, and it felt intuitive (we played defense). Now add to this some strafe buttons (and not another axis). I think for me personally I'd like this because this is similar to how games like ut2004, quake etc... work. Except they use a mouse for the orientation. The strafe buttons work where they inject more strafe the longer they are held down, and then release it in the same manner. This way if the driver doesn't want to do it... it is easy to focus on the basics.

One good way to really answer this question is to create a simulation and give it to a real student driver and let him decide if it is easy or not. I *hope* to do this... next summer. ;)

Taylor 20-12-2011 14:03
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1092537)
Now add to this some strafe buttons (and not another axis).
But then the strafe would be digital, not analog. Not saying this is good or bad; it's just something to be considered.

Ether 20-12-2011 14:04
Re: WCD vs. Swerve
 

Quote:
Originally Posted by JamesTerm (Post 1092537)
The other half will be the reverse of that where given the wheel angles and speeds, what is the current x, y and rotational (i.e. angular) velocities.
That is called the Forward Kinematic Problem, and for swerve it has no kinematic solution for arbitrarily chosen values of the wheel speeds and angles. See the discussion starting at the bottom of Page7 of this paper.

Quote:
For now let's ditch the tank steering 2 joysticks except to say that it can be done. I think FWD and RCW can be on one joystick where left and right perform the rotation (I believe this is called arcade drive)... Just this much is what we had this season on a WCD, and it felt intuitive (we played defense). Now add to this some strafe buttons (and not another axis).
See the list of driver interface suggestions on Page 1 of this paper.

JamesTerm 20-12-2011 14:21
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Taylor (Post 1092543)
But then the strafe would be digital, not analog. Not saying this is good or bad; it's just something to be considered.
That all depends on how you look at it... It is possible to swap out a button control on functionality that uses an analog intensity parameter. The idea is that the button starts digital, but then transforms to analog given the amount of time it is held down. I hope that makes sense.... it is like taking the joystick and moving it from zero to full intensity in a given amount of time.

The most important point of this is that if designed right it is easy to swap buttons with axis controls with minimal code change... or overhead. This is why I love c++. :)

JamesTerm 20-12-2011 14:26
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092544)


That is called the Forward Kinematic Problem, and for swerve it has no kinematic solution for arbitrarily chosen values of the wheel speeds and angles. See the discussion starting at the bottom of Page7 of this paper.
Thanks for this link as well... I am a bit surprised that there are no solution cases. In my mind the robot is going to do something for those cases, and I'd look at this from a physics standpoint... by applying a vectored force to each point and let the opposing forces cancel each other out. Perhaps this is over-simplified, but perhaps it is worth testing a solution like this against the problem presented here, and see how equal they become.

Ether 20-12-2011 14:38
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1092549)
Thanks for this link as well... I am a bit surprised that there are no solution cases. In my mind the robot is going to do something for those cases
I did not say there were no solutions or that the robot would not do something. I said there were no kinematic solutions. Take a closer look at the link I posted previously; the meaning of this is explained there.


Quote:
, and I'd look at this from a physics standpoint...
Kinematics is physics :-)

Quote:
by applying a vectored force to each point
This is dynamics (also physics). For arbitrarily chosen values for each of the four wheel speeds and steering angles, a dynamic analysis of this sort could be done. Write a paper when you're done.

JamesTerm 20-12-2011 14:59
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092553)
I did not say there were no solutions or that the robot would not do something. I said there were no kinematic solutions. Take a closer look at the link I posted previously; the meaning of this is explained there.
Kinematic until just now was Greek to me... thanks for pointing that out... I come from a kinectic and dynamic study of problems in my work on the game. I don't really understand these abstract terms to their fullest yet, but I do know the details of what I know just not really the scope and label of it. ;)

I find it interesting how dropping an adjective from a sentence can really change the meaning.

FWIW I am not good at writing papers, but I can submit some code example when I get to that point.

JamesTerm 20-12-2011 16:41
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Gdeaver (Post 1091360)
1640 has done 4 wheel independent drive, independent steering the last two years.
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).

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.

Ether 20-12-2011 17:50
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1092537)
The other half will be the reverse of that where given the wheel angles and speeds, what is the current x, y and rotational (i.e. angular) velocities.
Why do you want to do this?

JamesTerm 20-12-2011 18:18
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092595)
Why do you want to do this?
"Originally Posted by JamesTerm
The other half will be the reverse of that where given the wheel angles and speeds, what is the current x, y and rotational (i.e. angular) velocities.
"

For 2 reasons... one is to render the images position on our simulation. I use text graphics on OSG (open scene graph). The other reason is for autonomous where if I can interpolate the position on a 2D field I can calculate the desired velocity and orientation to hit a target.

I have achieved these tasks with WCD, but I have not yet confirmed angular motion (logomotion did not require that). I am still researching this, but I believe I can have accurate angular turns if I have reliable encoder readings of distance. Anyhow... none of this matters if we switch to swerve.

Ether 20-12-2011 20:07
Re: WCD vs. Swerve
 

Under what circumstances would you ever be commanding wheel speeds and steering angles that are not the result of an inverse kinematic calculation? If you are using kinematically correct speeds and steering angles for all four wheels, you should be getting the vehicle translational and rotational velocities which were used to compute those speeds and steering angles1. Use those vehicle translational and rotational velocities to render the image's position in your simulation.

If your concern is about rapidly changing operator commands and the dynamic response of your steering and/or drive motors, and you are envisioning measuring actual wheel speeds and steering angles and using them to figure out where the vehicle is over time, then yes, you would need a way to compute what the vehicle is doing at each moment in time based on the measured wheel speeds and angles. How do you propose to do this computation?


1 unless your wheels are slipping/sliding (due to an obstruction perhaps). In that case predicting vehicle motion accurately without additional sensors seems problematic.


Quote:
Originally Posted by JamesTerm (Post 1092604)
"Originally Posted by JamesTerm
The other half will be the reverse of that where given the wheel angles and speeds, what is the current x, y and rotational (i.e. angular) velocities.
"

For 2 reasons... one is to render the images position on our simulation. I use text graphics on OSG (open scene graph). The other reason is for autonomous where if I can interpolate the position on a 2D field I can calculate the desired velocity and orientation to hit a target.

I have achieved these tasks with WCD, but I have not yet confirmed angular motion (logomotion did not require that). I am still researching this, but I believe I can have accurate angular turns if I have reliable encoder readings of distance. Anyhow... none of this matters if we switch to swerve.

Ether 20-12-2011 20:46
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092656)
How do you propose to do this computation?
If the wheel speeds and steering angles are not too far from an inverse kinematic solution, the following computation may be adequate to estimate vehicle behavior:

Code:
FWD = (sFR*cos(aFR)+sFL*cos(aFL)+sRL*cos(aRL)+sRR*cos(aRR))/4;

STR = (sFR*sin(aFR)+sFL*sin(aFL)+sRL*sin(aRL)+sRR*sin(aRR))/4;

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);
... where:
L and W are wheelbase and trackwidth in inches

sFR, sFL, sRL, and sRR are wheel tangential speeds in feet/second

aFR, aFL, aRL, and aRR are wheel angles in radians clockwise from straight ahead

FWD and STR are vehicle velocity in feet/sec in the forward and strafe_right directions

and omega is the vehicle clockwise rotational velocity in radians/sec

JamesTerm 20-12-2011 21:22
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092700)
If the wheel speeds and steering angles are not too far from an inverse kinematic solution, the following computation may be adequate to estimate vehicle behavior:
Thanks so much for these equations! I am so happy that there is someone here who understands what I'm trying to do. :)

Now that you have submitted these... I gotta try them out and let you know how they behave... I hope to have something written in the next few days.

Thanks again!

P.S. I do as you say take actual measurments and work with these over a slice of time... the slice of time is measured in the main loop and submitted as a delta double seconds parameter through the entire cycle. (I do not use any other threads... i.e. my own PID).

JamesCH95 21-12-2011 08:37
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1092547)
That all depends on how you look at it... It is possible to swap out a button control on functionality that uses an analog intensity parameter. The idea is that the button starts digital, but then transforms to analog given the amount of time it is held down. I hope that makes sense.... it is like taking the joystick and moving it from zero to full intensity in a given amount of time.

The most important point of this is that if designed right it is easy to swap buttons with axis controls with minimal code change... or overhead. This is why I love c++. :)
If you do not want to use a joystick, I would suggest using the analog triggers on a game pad. This would allow the driver to have two joysticks and two analog triggers at their disposal.

JamesTerm 24-12-2011 01:07
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092700)
If the wheel speeds and steering angles are not too far from an inverse kinematic solution, the following computation may be adequate to estimate vehicle behavior:
I have been working with both equations and have had success with my first iteration (from velocity to the vars and back to velocity)... It appears the omega equation is almost twice as much as what it originally was. I've tweaked with the equation and found substituting the pi/2 with dimensions.lengh()/2... it falls short but is much closer.

dimensions.length is sqrt(l*l + w*w)

JamesTerm 24-12-2011 01:12
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesCH95 (Post 1092777)
If you do not want to use a joystick, I would suggest using the analog triggers on a game pad. This would allow the driver to have two joysticks and two analog triggers at their disposal.
Ah yeah that is cool as well... or better yet have the driver use the kinnect and lean to the left or right. ;)

JamesTerm 24-12-2011 11:51
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092700)
Code:
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);

This is what I have confirmed the omega equation to be:
Code:
const double omega = (((_.sFR*cos(atan2(W,L)+(HP-_.aFR))/4)+
(_.sFL*cos(atan2(-W,L)+(HP-_.aFL))/4)+
(_.sRL*cos(atan2(-W,-L)+(HP-_.aRL))/4)+
(_.sRR*cos(atan2(W,-L)+(HP-_.aRR))/4)));
Since it is just about Christmas I'll show you a similar equation I wrote (that helped me figure this one out)... This is what I use when appling a vectored force to a point within a rigid body.

Code:
void PhysicsEntity_2D::ApplyFractionalForce( const osg::Vec2d &force, const osg::Vec2d &point,double FrameDuration )
{
        //Use this as a "get by" if the code doesn't work properly
#if 0
        ApplyFractionalForce(force,FrameDuration);
        return;
#endif
        //Here is a rough draft to solve in 2 dimensions
        //A=atan2(py,px)  point
        //M=pi/2 - A
        //L=atan2(fy,fx)  force
        //N=L+M
        //Y=sin(N)*f.length = contribution for force
        //X=cos(N)*f.length = contribution for torque

        double TorqueToApply;
        osg::Vec2d ForceToApply;
        double RadialArmDistance;

        {
                double A=atan2(point[1],point[0]);
                double M=(M_PI/2) - A;
                double L=atan2(-force[1],-force[0]);
                double N=L+M;

                double ForceLength= sqrt((force[1]*force[1])+(force[0]*force[0]));
                RadialArmDistance= sqrt((point[1]*point[1])+(point[0]*point[0]));
                //I've reserved a special case for ships which haven't specified  their radius size, in which case we simply factor out the radial arm too
                if ((m_RadiusOfConcentratedMass==1.0)&&(RadialArmDistance>1.0)) RadialArmDistance=1.0;

                //Fr = t  ... We should multiply force by the radial arm distance to get the torque
                //but instead,  we pass it off to physics where the multiply gets applied directly against the Radius of Concentrated Mass
                //We could multiply here but doing it the other way keeps the torque value low, which also makes it easier to debug
                TorqueToApply=(cos(N)*ForceLength);
        }

        osg::Vec2d vecToCenter = -point;
        //Note we should be able to support a point set at 0,0,0 in which case we use the force itself as the direction... otherwise a zero'd point
        //results in a zero'd vector which would omit applying the force
        if (vecToCenter.length2()==0.0)
                vecToCenter=-force;

        vecToCenter.normalize();

        ForceToApply = vecToCenter * (force * vecToCenter);

        ApplyFractionalForce(ForceToApply,FrameDuration);
        ApplyFractionalTorque(TorqueToApply,FrameDuration,RadialArmDistance);
}

Ether 24-12-2011 14:11
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092700)
Code:
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);
Quote:
Originally Posted by JamesTerm (Post 1093584)
This is what I have confirmed the omega equation to be:
Code:
const double omega = (((_.sFR*cos(atan2(W,L)+(HP-_.aFR))/4)+
(_.sFL*cos(atan2(-W,L)+(HP-_.aFL))/4)+
(_.sRL*cos(atan2(-W,-L)+(HP-_.aRL))/4)+
(_.sRR*cos(atan2(W,-L)+(HP-_.aRR))/4)));
Assuming "HP" means "pi/2", then the equation you posted is arithmetically identical to the one I gave you, with the exception that you removed the final "/(sqrt(L^2+W^2)/2)"... which is required if you want omega to be in units of angular velocity (rad/sec).

There was a typo in my original post. The notes at the bottom said "L and W are wheelbase and trackwidth in inches". That should have said feet.

JamesTerm 28-12-2011 15:17
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1093614)
Assuming "HP" means "pi/2", then the equation you posted is arithmetically identical to the one I gave you, with the exception that you removed the final "/(sqrt(L^2+W^2)/2)"... which is required if you want omega to be in units of angular velocity (rad/sec).
HP means pi/2... I work in meters, so the other part wasn't an issue for me. Oh and each vector is divided by 4. I have a working demo here:

http://www.termstech.com/files/SwerveDriveDemo.wmv

The demo adds a layer of swivel management where it is paced to 18 radians per second on angular acceleration and only 270 degrees of freedom.

Thanks again for these equations... now I just need a swerve drive robot to put this software on. ;)

Ether 28-12-2011 15:35
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);


JamesTerm 29-12-2011 16:34
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!

Siri 30-12-2011 12:37
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

JamesTerm 30-12-2011 14:06
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Siri (Post 1094529)
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. ;)

Ether 30-12-2011 18:22
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.

JamesTerm 30-12-2011 19:33
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.

Ether 30-12-2011 19:41
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

JamesTerm 30-12-2011 23:18
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. ;)

Andrew Lawrence 30-12-2011 23:22
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. :)

Siri 31-12-2011 11:26
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1094730)
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. ;)
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! ;)

JamesTerm 31-12-2011 12:43
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. :)

Chris is me 31-12-2011 12:46
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!) 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! ;)
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.

Siri 31-12-2011 14:18
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Chris is me (Post 1094828)
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.
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?

davidthefat 31-12-2011 14:27
Re: WCD vs. Swerve
 
Just wondering, is there such thing as an "East Coast Drive"?

JamesTerm 31-12-2011 16:45
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! :)

Siri 31-12-2011 17:56
Re: WCD vs. Swerve
 
Thanks! I'll show your code to our programmers. I don't understand the coding (we use LabVIEW and I'm not a programmer), but the idea's really intriguing. The video would also be amazingly helpful. Thanks so much.

JamesTerm 02-01-2012 15:30
Re: WCD vs. Swerve
 
Quote:
Originally Posted by JamesTerm (Post 1094883)
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:
I have updated the code to support unlimited swivel movement 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();
                //This is normalized implicitly
                const double LastSwivelDirection=Swivel.GetPos_m();
                double DistanceToIntendedSwivel=fabs(NormalizeRotation2(LastSwivelDirection-SwivelDirection));

                if ((DistanceToIntendedSwivel>PI_2) ||
                        (Swivel.GetUsingRange() &&
                        ((SwivelDirection>Swivel.GetMaxRange()) || (SwivelDirection<Swivel.GetMinRange())))
                        )
                {
                        SwivelDirection=NormalizeRotation2(SwivelDirection+PI);
                        if (Swivel.GetUsingRange())
                        {
                                double TestIntendedFlipped=NormalizeRotation2(IntendedDirection+PI);
                                //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);
}
If anyone wants to see a new demo using unlimited swivel movement in the swivel angles let me know.

Siri: Our team is working on a new server for our web site... I am hoping they'll have this ready soon as I'll put that match (and the rest of them) on there.

Ether 02-01-2012 15:38
Re: WCD vs. Swerve
 

Quote:
Originally Posted by JamesTerm (Post 1095405)
If anyone wants to see a new demo using unlimited swivel movement in the swivel angles let me know.
I'd like to see it. Can you improve the resolution or make the image bigger so details can be seen?

JamesTerm 03-01-2012 14:45
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1095412)


I'd like to see it. Can you improve the resolution or make the image bigger so details can be seen?
I've over wrote the original demo (I didn't like it) so this link:
http://www.termstech.com/files/SwerveDriveDemo.wmv

Has the new changes.

Mike Soukup 03-01-2012 18:46
Re: WCD vs. Swerve
 
Quote:
Originally Posted by davidthefat (Post 1094844)
Just wondering, is there such thing as an "East Coast Drive"?
Yes, it's just a drive base with no appendages on top of it because all it's designed to do is play defense. Sorry Grady, I had to go there again. Those of you who have been around for a while will understand my humor. The rest will probably get upset.

JamesTerm 01-02-2016 10:45
Re: WCD vs. Swerve
 
Quote:
Originally Posted by Ether (Post 1092700)
If the wheel speeds and steering angles are not too far from an inverse kinematic solution, the following computation may be adequate to estimate vehicle behavior:

Code:
FWD = (sFR*cos(aFR)+sFL*cos(aFL)+sRL*cos(aRL)+sRR*cos(aRR))/4;

STR = (sFR*sin(aFR)+sFL*sin(aFL)+sRL*sin(aRL)+sRR*sin(aRR))/4;

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);
... where:
L and W are wheelbase and trackwidth in inches

sFR, sFL, sRL, and sRR are wheel tangential speeds in feet/second

aFR, aFL, aRL, and aRR are wheel angles in radians clockwise from straight ahead

FWD and STR are vehicle velocity in feet/sec in the forward and strafe_right directions

and omega is the vehicle clockwise rotational velocity in radians/sec
Yeah... I realize this thread has been asleep for several years, but for the good of the group... I'd like ask and/or solve these equations (both kinematic and inverse kinematic) for 6 wheels. Where the 4 wheels work as they have before here using the same variables ability to change speed and angle direction, as well as other variables (e.g. wheelbase and trackwidth) as much as possible. But then have 2 extra wheels in the center... for my own requirements, I'd like the width distance between the center wheels to be a bit wider than the corner wheels... this helps minimize friction when it rotates, such a configuration of drive can be observed on say the Mars Curiosity drive, except the center wheels on this are fixed. That said... if it is easy to produce equations for center wheels fixed that would be nice to know, but ideally for the sake of having other 6 wheel drive solutions... if they can swerve as well that would be ideal set of equations to solve. Any feedback will be greatly appreciated... Thanks.


All times are GMT -5. The time now is 18:32.

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