Different Swerve Drives

[CalTran]

As soon as I get the project write up done I will post it to CD as a white paper and y'all can have at the critiques.

Originally Posted by Jon Stratis

Oh, and to ensure position/rotation of the wheels, you'll want to have feedback on them. I would suggest a potentiometer - this can tell your code exactly which direction each wheel is pointing, and would be a bit simpler than an encoder.

We figured if we can't get infinite rotations in then a pot would be the simplest method for checking rotation. We've had experience with them (Logomotion arm and our use of a pot won us Rockwell Innovation in Control award at Greater KC)

Originally Posted by Alpha Beta

In 2010 we loved using a mercury slip ring from Mercotac. I believe we had some donated. They were later outlawed that year and we switched to a twisting loop of wire and used software to keep track of how many twists we had undergone. I think recent rules have allowed for them again.
In 2011 1717 steered the opposite corners together, allowing them to create a diamond wheel pattern and spin in place to reorient. That would have been our next iteration had we continued with swerve.

Two things about this post:
1. Slip rings. We looked into the wikipedia, and we think we understand how they work but if someone could give us a somewhat more simple explanation for us to check against that would be appreciated.
2. How would one go about steering opposite corners without using a motor per corner? We would like to keep things chained together for sake of simplicity, but with the talk of simplicity on the other side of complexity, if one can justify using individual motors but programming them as 2 motors (ie utilizing a pwm y cable) then we'll take that. I imagine that if we do use individual motors but code them as 2 then it might make a transition to full individuality simpler.

Originally Posted by Alan Anderson

You can completely avoid the problem of getting electricity to a motor that swerves with the wheel. Using coaxial shafts and bevel gears, you can keep the motors stationary and transmit mechanical power through the rotating parts.

We've thought about using bevels or miter gears before to transfer power but the calculations and precision necessary aren't exactly something our team are known for.

Yes this sounds somewhat counter intuitive to creating a swerve drive if we can't pull off something extreme, but we think that if we can keep the swerve drive as simple as a swerve drive can get then we might be in the clear.

Originally Posted by Aren_Hill

But the resource drain is enormous, and for that reason I do not see us pursuing it in the near future, I'd like to save some time for other parts of the robot so we can put on a little bit better show than this weekend (we were very very far from prepared due to other circumstances).


The technical learning benefits of doing a swerve on the other hand are enormous, from Concept to CAD to Machining to Programming to Driving, you learn an incredible amount due to the complex nature of the system and the level of performance you could potentially extract from it.
For that reason pursuing a prototype in the offseason is fairly okay, just be watchful of the "man this is so cool we should do it in build" as I've embarrassingly fallen victim to it so many times before, with varying results.

As far as the resources go, our school district is fortunate enough that research projects get a somewhat substantial budget, though it isn't quite a black budget. As long as we can minimize the cost and we're not attempting to buy the moon we're alright.

As far as the technical learning benefits, that is one of the reasons we would like to pursue this. Myself and a few other kids are in a pilot FIRST Robotics Engineering class, and with CowTown over (Our only off season), we're looking for something to do each day for 2 hours until season.

This being said, we are also going to do a project write up for a 6 or 8wd that may be used in season. Should it be necessary I will open another thread with similar purpose to this thread about that drive. Also note that should we only be able to do one project, the 6/8wd project will take precedent over this project and swerve will be shelved as a theoretical project.

[Siri]

Originally Posted by CalTran

1. Slip rings. We looked into the wikipedia, and we think we understand how they work but if someone could give us a somewhat more simple explanation for us to check against that would be appreciated.

What they do
Small cylinders with wires protruding from both faces: you hard put them along your wire runs at the stationary-rotating interface of your swerve modules. One side's wires turn; the other side's stay still.

How they do it
The classic version (I think they're all like this?) and simplest way to think about it is that each stationary wire has a little brush on the end. Each brush sits on a metal ring which can rotate while still allowing the signal to transfer.

Does that work?


Ether: Good point. That'd be pretty neat!

[CalTran]

I'm back with another question/update on our process. During the mechanical design write up of this project, a mentor and I conversed about the decision to chain sides together - and he suggested we attempt full independence. His reasoning is that the long chain runs that would be necessary would be invitations to the chain hitting something then skipping. Another thing he brought up not previously thought about was the investment of space necessary to chain sides together. I also believe we will be doing Co axially driven pods, as the infinite rotations and gearing would be somewhat advantageous.

[MichaelBick]

Originally Posted by CalTran

I'm back with another question/update on our process. During the mechanical design write up of this project, a mentor and I conversed about the decision to chain sides together - and he suggested we attempt full independence. His reasoning is that the long chain runs that would be necessary would be invitations to the chain hitting something then skipping. Another thing he brought up not previously thought about was the investment of space necessary to chain sides together. I also believe we will be doing Co axially driven pods, as the infinite rotations and gearing would be somewhat advantageous.

As long as you have enough motors in the kit I would recommend going with the independent steering. It is mechanically simpler, and allows faster change of modules.

[Gdeaver]

After doing swerve for 3 years, I strongly agree with MICHAEL that independent steering modules are the way to go. Swerve has many more failure modes. Having chain runs all over the robot is a night mare to work on at a competition in the pits. Our swerve modules require the removal of 4 bolts and disconnection of 3 pairs of wires to remove a module. We can remove and replace a problem module and get on to the next match. Repair it later. Doing swerve is going to increase the complexity of the robot. Try to minimize the added complexity.

[Jeffy]

Cal,

I am excited to hear the team is interested in taking on a challenge like this.

Knowing the resources that 2410 has and an idea of the teams other
constraints like, money, time and talent. I would say look closely at how 973 does their swerve. What I think is really nice is that each swerve section is it's own module that is then bolted to the frame. I believe this method is something that is easily visualized, delegated and tweaked. Build 4 identical modules and a box frame with a plywood electronics board. Very solid testing module.

If you need any help, you know how to find me. Good luck!

-Jeff

P.S. send me CAD

Edit to add:
Cimple gears paired with 4 inch wheels seem to make a really nice combo.

[CalTran]

Update 11.8.12

After evaluation, the team has decided to do coaxial rather than distributed. With deliberation between our programmers and me, it was decided that working with an extended travel potentiometer is much simpler for them to do rather than working with an encoder. (Coding will most likely be done in C++, for those wondering.) Our decision is thus because we believe it will be easier in the future to switch to an encoder from potentiometer once we decided we would like more than one rotation. However, some more deliberation will be had once we can get in touch with some of our mentors from Rockwell Automation.

Also, at Jeffy's advice, I went over to FRC Designs and have dissected the Emperor Swerve corner module.
One of the things I am wondering about after looking at this design is how to design for the rotation. From what I can see in the CAD file, the wheel module is set inside a steering bearing and this is what allows for the wheel to rotate. Correct?

As well, we believe that the frame of our testing bed will be 80/20 extrusion, with the modules designed to slide on and off of the frame. As well as testing Swerve Drive on the platform, we will also look into a well-designed 6/8 wheel drive that could be slid on to the platform, so as to consolidate pricing of off season prototyping.

As a last point of note, when teams do fabricate the modules, how many are created? Four would be the minimum* (No spares), and I suppose the cap would be where you want to stop spending money on creating modules. Are two extra modules a happy medium to stop at? That would mean that we would need to fabricate six total modules.
*Note, Bomb Squad’s three wheel swerve is excluded from this analysis.

*Edit: http://www.chiefdelphi.com/forums/sh...Emperor+Swerve has shed some light on the various mountings and bearings necessary for rotation.

[Ether]

Originally Posted by CalTran

working with an extended travel potentiometer is much simpler for them to do rather than working with an encoder

NAND, but can you please explain why?

[CalTran]

The main reason the programming team came back with is that it is simpler to do one analog in from the potentiometer than multiple digital or a serial input(s) from an encoder. Also, from the preliminary research they did, pricing was a little higher than we'd like to do for an encoder. Both will work for our needs, but in terms of complexity we'd like to keep it simple, and the programmers said a pot would be the better of the two in that aspect.

[AdamHeard]

Originally Posted by CalTran

Update 11.8.12

After evaluation, the team has decided to do coaxial rather than distributed. With deliberation between our programmers and me, it was decided that working with an extended travel potentiometer is much simpler for them to do rather than working with an encoder. (Coding will most likely be done in C++, for those wondering.) Our decision is thus because we believe it will be easier in the future to switch to an encoder from potentiometer once we decided we would like more than one rotation. However, some more deliberation will be had once we can get in touch with some of our mentors from Rockwell Automation.

Also, at Jeffy's advice, I went over to FRC Designs and have dissected the Emperor Swerve corner module.
One of the things I am wondering about after looking at this design is how to design for the rotation. From what I can see in the CAD file, the wheel module is set inside a steering bearing and this is what allows for the wheel to rotate. Correct?

As well, we believe that the frame of our testing bed will be 80/20 extrusion, with the modules designed to slide on and off of the frame. As well as testing Swerve Drive on the platform, we will also look into a well-designed 6/8 wheel drive that could be slid on to the platform, so as to consolidate pricing of off season prototyping.

As a last point of note, when teams do fabricate the modules, how many are created? Four would be the minimum* (No spares), and I suppose the cap would be where you want to stop spending money on creating modules. Are two extra modules a happy medium to stop at? That would mean that we would need to fabricate six total modules.
*Note, Bomb Squad’s three wheel swerve is excluded from this analysis.

*Edit: http://www.chiefdelphi.com/forums/sh...Emperor+Swerve has shed some light on the various mountings and bearings necessary for rotation.

Keep in mind that the link you posted is a thoroughly different design in regards to bearing setups.

I like to think that our steering bearing setup, and what 1717 did, are about as simple as you can get. It's just two radial bearings spaced apart to react torque and radial loads, and then a large thrust bearing to react the robot weight.

[MichaelBick]

Originally Posted by AdamHeard

Keep in mind that the link you posted is a thoroughly different design in regards to bearing setups.

I like to think that our steering bearing setup, and what 1717 did, are about as simple as you can get. It's just two radial bearings spaced apart to react torque and radial loads, and then a large thrust bearing to react the robot weight.

To clarify on adam's post, the bearings that 973 ran is discussed by adam lower down in that thread.

[CalTran]

Originally Posted by MICHAELABICK

To clarify on adam's post, the bearings that 973 run is discussed by adam lower down in that thread.

Yeah I was referring to the discussion, not the bot in the title. Sorry for giving a scare ::