Be afraid... Be VERY Afraid

[Siri]

When you say "both wheels are actuated", it sounds as if you mean independently actuated--if so, along what line of action?

If not, what we have is a pivoting drivetrain module with two wheels at different gear ratios and diameters. The wheel are indeed drive wheels, powered simultaneously but contacting independently (meaning the treads shown contact the ground one at a time?) The special thing has something to do with changing the 3D position and/or its first derivative with respect to the chassis on which these units are mounted. I feel like it has something to do with being able to turn. As it stands, this seems like it would be really bad at turning--at least versus the work put into it--but it's definitely not swerve...
EDIT: Bryan beat me to #2 and 3 (though he did 3 way better than I did).

All that, and you know what bugs me? that little peg thing inside the triangular pivot axle support. What's up with that thing?

[DanielDTech]

Hey everyone, I'm really sorry for what this turned into. It wasn't my intention to seem like I'm trolling you guys. I'm completely new to this community; I made an account just to post the render. I wasn't even aware that it was so populated here at this time of year... Thankfully, Akash Rastogi found me on facebook and explained why this post was so controversial. Again, I didn't really know how things worked here at CD until Akash and others who posted here cleared it up for me.

I was hesitant to post the actual thing because we wanted it to be a surprise during the season, if the game even accommodates this drive, that is... But anyway, here's something to clear things up. Sorry about all this. I hope you guys can forgive me!

[Joe G.]

First off, thank you!

Second off, sweet CAD!

Third, questions/constructive criticism (see how we can do that now? )

It appears that there is nothing that retains the ball vertically other than the robot's weight. I can assure you that even with a level field, you'll want to address this. The robot can be lifted up in collisions (not to mention carrying it on and off the field). If this is simply not yet modeled, disregard this comment.

What kind of bearings will you be using to support module rotation?

What kind of traction material will you use on the ball, and ball/roller interface? Fears of slip/low traction have always deterred me from ball drive.

The idea of shifting roller sizes on a ball drive for shifting is very cool, though I agree that as modeled, I don't see the advantage over a swerve with traditional dog sifters. I feel like this may have the potential to be more compact though, maybe by shifting the CIM down low, behind the ball. If there's an advantage I'm missing, please enlighten me though!

The initial module you posted looked like it had a lot of promise as a traditional wheel-switching shifting design. While not totally original, your design work was sound and compact. Maybe pursue this as well.

[DanielDTech]

Originally Posted by Joe G.

First off, thank you!

Second off, sweet CAD!

Third, questions/constructive criticism (see how we can do that now? )

It appears that there is nothing that retains the ball vertically other than the robot's weight. I can assure you that even with a level field, you'll want to address this. The robot can be lifted up in collisions (not to mention carrying it on and off the field). If this is simply not yet modeled, disregard this comment.

What kind of bearings will you be using to support module rotation?

What kind of traction material will you use on the ball, and ball/roller interface? Fears of slip/low traction have always deterred me from ball drive.

The idea of shifting roller sizes on a ball drive for shifting is very cool, though I agree that as modeled, I don't see the advantage over a swerve with traditional dog sifters. I feel like this may have the potential to be more compact though, maybe by shifting the CIM down low, behind the ball. If there's an advantage I'm missing, please enlighten me though!

The initial module you posted looked like it had a lot of promise as a traditional wheel-switching shifting design. While not totally original, your design work was sound and compact. Maybe pursue this as well.

We are aware of the vertical ball retaining issue. This is not the completed unit. Like I said, I only posted the remainder of what needed to be posted so one could know what this is. We still have some design and innovation to do here, and we'll be vigorously working on this until kickoff.

Unfortunately I have to hit the sack because I have to wake up early tomorrow, but I'll back tomorrow to talk about the mechanism...

[Kevin Selavko]

How big each of the modules, and how many of these modules are you planing to have, 3 or 4? Do you think that there will be enough room for the full size of the swerves plus their turning motors/gears/belts? Another possibility is to use a mouseball kind of thing with omnis, this would also allow for strafing.

Also why are the wheels two different sizes?

[dcarr]

Originally Posted by DanielDTech

We are aware of the vertical ball retaining issue. This is not the completed unit. Like I said, I only posted the remainder of what needed to be posted so one could know what this is. We still have some design and innovation to do here, and we'll be vigorously working on this until kickoff.

Unfortunately I have to hit the sack because I have to wake up early tomorrow, but I'll back tomorrow to talk about the mechanism...

Make sure that you follow the rules when making your decision to use (or not use) your drivetrain in the 2013 season. With only 40 days to go, it may be pretty difficult to complete a prototype before kickoff. Something to think about.

From the 2012 Manual, section 4.1.4.

R18

Robot elements designed or created before the Kickoff presentation, including software, are not permitted.

Please note that this means that Fabricated items from Robots entered in previous FIRST competitions may not be used on Robots in the 2012 FRC. Before the formal start of the Robot Build Season, teams are encouraged to think as much as they please about their Robots. They may develop prototypes, create proof-of-concept models, and conduct design exercises. Teams may gather all the raw stock materials and COTS Components they want.

Example: A team designs and builds a two-speed shifting transmission during the fall as a training exercise. When designing their competition Robot, they utilize all the design principles they learned. To optimize the transmission design for their Robot, they improve the transmission gear ratios and reduce the size, and build two new transmissions, and place them on the Robot. All parts of this process are permitted activities.

Example: The same team realizes that the transmission designed and built in the fall perfectly fits their need for a transmission to drive the Robot arm. They build an exact copy of the transmission from the original design plans, and bolt it to the Robot. This would be prohibited, as the transmission – although fabricated during the competition season – was built from detailed designs developed prior to Kick-off.

Example: A team developed an omni-directional drive system for the 2011 competition. Over the summer of 2011 they refined and improved the control software (written in C) to add more precision and capabilities. They decided to use a similar system for the 2012 competition. They copied large sections of unmodified code over into the control software of the new Robot (also written in C). This would be a violation of the schedule constraint, and would not be allowed.

Example: The same team decides to use the LabVIEW as their software environment for 2012. Following kickoff, they use the previously-developed C code as a reference for the algorithms and calculations required to implement their omni-directional control solution. Because they developed new LabView code as they ported over their algorithms, this would be permitted.

Example: A different team develops a similar solution during the fall, and plans to use the developed software on their competition Robot. After completing the software, they post it in a generally accessible public forum and make the code available to all teams. Because they have made their software generally available (per the definition of COTS, it is considered COTS software and they can use it on their Robot).

[sanddrag]

The Technokats did a ball drive in 2003, and I think Andy Baker went on to patent the idea. There's a thread on it somewhere around here.

[Gregor]

http://www.chiefdelphi.com/forums/sh...ght=ball+drive

[dcarr]

Originally Posted by sanddrag

The Technokats did a ball drive in 2003, and I think Andy Baker went on to patent the idea. There's a thread on it somewhere around here.

A quick Google search uncovers a couple threads and videos including balancing on the 2012 bridge

As awesome as this is, I would be interested in a breakdown of the pros/cons of choosing something like this versus a well-implemented swerve (a la 1717, 973, etc.). I'm not seeing any benefits, but I have only a cursory understanding of drivetrains at the moment.

[bhumudar]

Let me start by saying that I have also spoke to Daniel about etiquette on the forms and am happy to see his attempt at rectifying the situation. With that being said this design is by no means a finished product. We are still hard at work picking out all the little details so that we can have a smooth running drive-train for this year. In addition to that, we are not yet certain if this will even be the drive-train system that we will be using for this years game, considering we know very little to nothing about what it really is. Finally, as much as I did not want to disclose so much detail on the design we have so far this early on I suppose the design is now up for discussion. The other half of the magic is in the programming anyways So have at it!!!

I'm excited to see everyone at kick-off, see you then!

[Siri]

I'll try to limit it to 5 questions:
1. What's the advantage of this versus standard swerve?
2. What language are you programming in, and how far have you gotten?
3. What cylinder are you using, and how is it mounted? What's the normal force between the rollers and the ball, and what're the CoFs?
4. What's the total module weight and how does the chassis interface work?
5. What experience will you have with this by kickoff? As it stands, I have to echo R.C.'s comment. I've known--and have been--a first-year swerve team. In all honesty, it looks like you're setting yourself and your alliances up for trouble jumping in on January 5th. Good luck either way, though.

[Peyton Yeung]

This past summer I revived team 45's ball drive and it has seemingly lack-luster results. While it is much simpler than your current design it still doesn't perform as well as some swerve drives I've seen and driven. If you can get it working more power to you. If you want, PM me and I can send you more pictures of our 2003 ball drive robot and give you a good list of pros and cons.

[bhumudar]

1. There are two advantages that we have seen so far. The first is a serious weight reduction as we don't need AM shifters. Also the ball will be made of carbon fiber wrapped in some undecided traction material. We also get a bit more friction if we were lets say trying to be pushed by another robot. This is due to the fact that we can put the driving wheels perpendicular to the incoming force, thus allowing the friction between the ground and the ball as well as the driving wheel and the ball. The second advantage is that we can easily disengauge the ball completely and use it as a "castor wheel".

2. LabVIEW. We have written some preliminary algorithms for the basic driving. We are now working on automating some maneuvers.

3.We still haven't decided on the exact cylinder, but will most likely use the tiny cylinder in the KOP (I can't remember the bore size). It will be mounted on a pivot point at an angle from the floor to the right of the big drive wheel.

4. We are aiming at less than 3 lbs (without including the CIM). This will depend on what materials we use (carbon fiber, aluminum, titanium). It will be a modular plugin to the chassis.

5. I have taken this into consideration, so in response, we will only be using this system if it is successfully running in a fair amount of time.

[Siri]

Cool! Thanks. Followups:

1A. I'm missing how you get "more friction". Isn't the first place you slip the only one that matters? I guess I'm not understanding what you intend to do (in part because of Chris's question).

1B. What's the benefit of turning it into an caster wheel in this setup?

4. Wow, 3 pounds? Keeping that in-cost is definitely impressive. What's the ball diameter?

[bhumudar]

Siri,

1. You are correct in that the first place that you lose friction is the only one that matters, but since there are multiple contact points, each one adds to the total friction available. Lets suppose you see an incoming robot front the right of our robot, we would turn the wheels so that they face front to back (perpendicular to the incoming force).

2. It would simply be used as a built-in neutral position which may or not help with this years game.

3. I believe the diameter is about 4 inches.