View Single Post
  #3   Spotlight this post!  
Unread 29-04-2012, 14:19
kmcclary's Avatar
kmcclary kmcclary is offline
Founder 830/1015;Mentor 66/470/1502
FRC #0470 (Alpha Omega Robotics)
Team Role: Engineer
 
Join Date: Aug 2001
Rookie Year: 1994
Location: Ann Arbor, MI
Posts: 491
kmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond repute
Re: pic: FRC488's Octocanum Ver 2.0

Originally, RyanCahoon wrote:
> Are you referring to potential for the force vector of a wheel to change if the pods deflect under load, leading to the forces from the wheels not summing correctly?

Quote:
Originally Posted by pfreivald View Post
That, and our machine tolerance aren't precise enough for me to be able to guarantee that the weight distribution is exactly right. As long as your frame is square and the mecanum wheels are mounted to it, this isn't a problem.
At first I was a fan of using "articulated sub-frames", for one of the pair of wheels, to rock them from side to side at their mid-line midpoint. Some of my early teams used this approach when attempting mecanum drives. It creates a "virtual tripod", which as you know from a three legged stool will ALWAYS sit flat on the floor. That evenly distributes the weight amongst the four wheels, and totally eliminates any "vector sum" problems.

However, from experience I've found that as long as you are working on a flat, carpeted surface (no ramps, et al) and avoid focused weight points on your robot, then the normal "twist give" of the basic C-Frame kit more than accounts for sufficient flex to keep all four of the wheels flat to the floor, and under proper load.

So (to keep this On Topic), as long as mounting the payload doesn't stiffen up this chassis too much, IMO 488's design should have more than sufficient flex to keep all four mec wheels on the ground on flat-surfaced games.

BUT... If you have to deal with RAMPS, I'd definitely consider going with the rocker sub-frame trick. Just place it on the FAR end from where your main gripper action occurs, to keep the gripper's orientation stable WRT the main frame.

BTW... As the arms are long between the two ends of the cylinders (and their pull motion is at 90 degrees to a rocker) should you DO decide to add a rocker sub-frame, then as long as the arm ends don't bind I'm not sure if you'd even have to go to independent cylinders for wheel switching!

NOTE: With rocker sub-frames, just be sure to LIMIT their motion to only a FEW degrees of rock, JUST enough to deal with keeping all four wheels on the ground!! Otherwise, you can risk flipping the bot if a wheel slips off the edge of a ramp, or encounters any other major field discontinuity!

This happened to us a few years ago, when we had to start the bot on a ramp. In one match one of our rocker sub-frame's wheels slipped off of the ramp edge during Autonomous. The rocker frame promptly spun over 45 degrees trying to keep all feet on the "ground". That let the robot tilt WAY over. The CG quickly went wonky, and the entire bot fall off of the ramp and onto its side...
We have since have added "motion limiter brackets" whenever we have a rocker sub-frame design, to limit it to JUST a few degrees of motion.

Quote:
Originally Posted by pfreivald View Post
In theory, every mechanical issue can be fixed by adding sensor feedback and offloading the issue to the programmers, right?
... Actually, I agree that having an independent measurement of performance is always USEFUL (for precision guidance during Autonomous, Field-Centered Navigation [FCN], etc).

But... As long as you have enough chassis twist flex to keep all four mecanum wheels firmly on the ground, IMO that becomes a bonus, not an absolute requirement.

IMO, just having a gyro in the sensor mix to account for orientation is often sufficient, even when implementing FCN. Since Auto is only 15 seconds long (and these days most game designs have been drifting toward having little or NO interaction with opposing robots during that time... <yawn>), I'm guessing that as long as you do not expect traction loss during Autonomous, then simple wheel encoders on the mecanum gearboxes may still be more than sufficient for implementing a decent Auto mode navigation routine.

YMMV though. If you are intending a really complex, far ranging Autonomous Mode (or we DO ever get back to being allowed to mess with opposing alliances during Auto Mode... Ah, the "Good Old Days"... ), then by all means add in the external sensors (follower wheels, gyros, etc) to support an independent "opinion" of where you are.

- Keith
--- Also the List Dad of "OmniMec" - An omnidirectional and mecanum wheel specialty e-list ---
__________________
Keith McClary - Organizer/Mentor/Sponsor - Ann Arbor MI area FIRST teams
ACTI - Automation Computer Technologies, Inc. (Sponsoring FIRST teams since 2001!)
MI Robot Club (Trainer) / GO-Tech Maker's Club / RepRap-Michigan) / SEMI CNC Club
"Certifiably Insane": Started FIVE FRC teams & many robot clubs (so far)!
2002: 830 "Rat Pack" | 2003-5;14: 1015;1076 "Pi Hi Samurai" | 2005-6: 1549 "Washtenuts"/"Fire Traxx"
2005-(on): 1502 "Technical Difficulties" | 2006-(on): FIRST Volunteer!
2009-(on): 470 "Alpha Omega" | WAFL | Sponsor & "Floating Engineer" for MI Dist 13 (Washtenaw Cnty)
2011: 3638 "Tigertrons" | 2013-(on): 4395 "ViBots" | 2014-(on) 66 "Grizzlies"
"Home" Teams: 66, 470, 1076, 1502, 4395
Local FIRST alumni at or coming to Ann Arbor (UM/EMU/WCC/Cleary)?
...We Want YOU as a Mentor! Please email me for info!
Support CDF Reputation - If a posting helped, thank 'em with rep points!
"It must be FRC build season when your spouse and children become 'Action Items 8 & 9'..."
Reply With Quote