Had a team made a swerve drive where only one motor is used to rotate the wheels? I feel this design could maybe save weight as well as save on power consumption/CPU usage. If you had 5 motors instead of 8 then it could draw less power theoretically.
Many times. This style is often referred to as a crab drive.
It is primarily used to make programming and driving more straightforward. However, it also takes away a lot of the versatility of a swerve drive, removing the ability to perform maneuvers which require wheels facing different directions. Additionally, the motor power required to steer four modules is not trivial, and a rather torquey motor is necessary.
do you mean rotate the wheels, as in steering them? or as in driving them?
Took me a bit, but here is a 2009 robot from 1405 that does this.
Generally it is quite a bit more difficult to sync the steering rotation of the wheels if you use more than 1 motor to steer. Considering all you need is one good motor I just can’t think of many good reasons to do it with multiple steering motors.
A few years ago FRC11 did steer a swerve drive with 2 steering motors. It did not end well but it did get a programming award trying to sort out the ‘Tazmanian Devil’ issues with steering and synchronizing 2 position targeted PID loops. It also pushed the limits of what we could pull off with Java on the cRIO because there were many motion control issues that had to be contended with.
Given the 6 week build window there would have to be a great reason to engage in these acrobatics instead of a simple piece of chain and one motor.
The reason you would use multiple turning motors is so that you can strafe and turn at the same time. If you chain all rotations together, you need to scrub when turning.
Crab drives use one motor to steer. I have never heard of a swerve drive module that uses the same motor to steer and turn the wheel.
The archetypal example of crab drive (that is, a number of swerve modules all steered together) is Tumbleweed, 148’s FIRST Overdrive robot, which had three wheels all driven off of one massive drive train. Because Tumbleweed had no manipulators, the orientation of the robot did not matter so crab was perfect. If you have a manipulator on a crab robot, you will almost certainly need to have that manipulator be able to rotate relative to the chassis to achieve what the chassis does not.
Robonauts have a great video showing off some of the points discussed here.
https://www.youtube.com/watch?v=CAJBC-DDL9w (2008)
They spoke about the drive train in 2009. The fundamental problem with steering all four wheels together is simply aligning the wheels so they all point the same direction to begin with. This is why their pods are designed the way they are, and why the 221 product is based upon their design.
A majority of the competitive swerve drive in the past couple of years have had one steering motor per module. Namely teams like 1717, 368, 16, 2471, and many more use it to give them more versatility in the ways they can position their wheels.
I’ve heard of a theoretical 3 sim swerve.
It’s not just theoretical, it was designed and implemented very successfully, and even posted on this thread earlier. Well, strictly it’s not 3 CIM, but it uses only 3 swerve modules, which I assume is what you meant.
This is how I imagine everyone in this thread responding to OP.
…because, strictly, three is not equal to four. And the little monster had two FPs as well, bringing its total propulsion power nearer to that of six CIMs. Underweight and overpowered – the thing could fly. 
Agreed it gives you more degrees of freedom of control. Thing is you have to be able to control it.
That is the core issue. If you confine your swerve build to just the 6 week build season, even if you buy the modules (which by definition means you just bought someone else’s development time), will you be able to achieve good control? The teams I have seen achieve this devoted good time to this task and the reward was fully exploiting it. They often did this work over several seasons or with extensive off season exploration.
Outside that…
I’ve thought this over quite a bit. As the OP mentions the cost of 4 CIM motors/speed controls to drive steering indepently is pretty high. 8 CIMs risks a good hunk of battery power in addition to driving weight. One could counter that you only use the steering CIMs when you steer but is that not the goal? Assuming one tames the power required or uses a smaller motor with sufficient gearing to steer to overcome this…
Is this really a mere 6 week task to gain a degree of freedom that as others have pointed out risks reducing your ability to drive straight?
If I could do swerve in FRC again (my team’s experience was so bad they always opt out) I would not do it with the expectation it will be fully polished in just 6 weeks. I could not justify the risk even if I know the task is doable in the general sense. I can easily see doing swerve outside of FRC where I have my choice of hardware and controls.
Can anyone provide examples of teams that jumped into swerves cold in a 6 week build season and fully exploited it? I am honestly curious my experience is limited to the northeast US. I would be very curious if they bought the modules or borrowed their code to make it work in that timeframe. I can accept it is possible but would like to understand the details.
I belive the late team 1717 did just that in 2009, or at least that is what the new cool made it sound like.
Per this post:
http://www.chiefdelphi.com/forums/showpost.php?p=1173711&postcount=34
Confirmed here:
http://www.chiefdelphi.com/forums/showpost.php?p=1178848&postcount=102
2000 hours for 5 mentors and 5 students is basically 2 6 week build seasons if you work around the clock.
Still a highly impressive effort and result.
Here is the evolution of their swerve steering over several years:
http://www.chiefdelphi.com/forums/showpost.php?p=1174293&postcount=61
Even if it is 2000 man hours which could be 200 hours each for 10 people - they built variations for years so by the time they built 4 wheel independent steer they already had design, build and drive experience.
696 in 2015. I don’t know what you mean by “fully exploited” but it was fully programmed and functional to do whatever you want. It stacked all three totes in autonomous a few times too. Did we drive it to its fullest capacity? Maybe not. But we didn’t have a practice bot either. Details at http://2015blog.team696.org
That is very impressive!
You’ve got a unique swerve design in 6 weeks.
Do you normally build practice robots?
Or put another way:
Did making the swerve drive contribute to the decision not to make a practice robot?
I ask because on Day 4 of the build log at the link it is suggested that the build schedule was to give enough time to practice before bag and tag.
In Leadership, an important schedule was made by Jack, the president, on the due dates of manufacturing. This is an important step in planning out the rest of the season as we hope to have a few days of drive practice before the robot has to get wrapped up and tied.
It looks like from the build log that the drive train was operational by mid-February?
That did not leave much time to practice.
In part, yes.
Your team made a very impressive practice bot in 2014, I found pictures of it.
So if the swerve drive contributed to the decision not to build a practice robot that would mean there was less opportunity to practice and the build was finished pretty close to bag and tag.
I guess the question that would raise, is the same that you’ve previously hinted at, did the swerve drive deliver sufficient advantage to the human operators or might the time and resources have been better directed at more simplistic drive train that the drivers could have had more quickly and perhaps had a practice robot as well?
Regardless it is an impressive achievement.
When we tried the swerve we also did not build a practice robot. We bought the modules but we weren’t able to get the drive train until the last 3 days. Plus we could not afford enough modules to make a practice robot.
The first time we really drove was on the field. I have always speculated that if we had gotten it all together a little sooner and if we had sorted out the programming challenges a bit sooner: that we might have been more successful.
Instead the drivers literally got the short end of the stick. A hard to control robot they had very little experience with and it was hard to make it go straight. Plus that was the year with the opening you could drive through in the field separator. Imagine threading a needle blind with something unpredictable.