View Single Post
  #60   Spotlight this post!  
Unread 03-04-2011, 23:57
Nikhil Bajaj Nikhil Bajaj is offline
MATLAB Fan
FRC #0461 (Westside Boiler Invasion)
Team Role: Mentor
 
Join Date: Feb 2003
Rookie Year: 2002
Location: West Lafayette, Indiana
Posts: 101
Nikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond reputeNikhil Bajaj has a reputation beyond repute
Send a message via AIM to Nikhil Bajaj
Re: The Hardest Drive System To Program:

Quote:
Originally Posted by aaronweiss74 View Post
I'm going to have to agree with all those who said that programming the drive system really isn't difficult at all. The most common systems are ready-made and quite frankly, there's absolutely no good reason other than elitist-ness to rewrite them. If you take programming in FIRST as an opportunity to prepare for programming in the real world, you'll have to realize that you get paid to produce new work, not rewrite already working code. As the old saying goes, don't fix what isn't broken. As for an actual answer, it has to be something complex to the point where you require advanced math, many motors, and coordination of such motors. Or something like what's already been mentioned where you switch between some or many drive systems. Walkers, tripods, and things of that sort will always be more difficult than a wheel system though.
The difficulty of programming a drive base is only related to how much work you want to put into it. Getting the bare minimum of functionality with any drive base is pretty easy, I'll agree, but you can always push, and push, and push the boundaries, even with a simple tank drive. Some things I have seen beyond just the basics in FRC:

-Traction Control (really helpful to a lot of teams in Lunacy)
-Automatic, precise turns (really great in Overdrive)
-Automatic straight driving code (also awesome in Overdrive)
-Automatic current-sensing based shifting
-Automatic anti-tipping code (Overdrive)

And those are still relatively simple, as those can all be done with just kinematics or simple PIDs with the right sensors. You could push still farther. If you integrate odometry and/or localization systems, you can start to do path planning and following. You can start integrating knowledge about system dynamics to better the path following. You can move up to state-space and non-linear control, and optimize your robot motion for speed and stability given actuator limitations. You can actually make statements like, "This is the fastest my robot can move across the field and keep the sway of my lift under a certain amount." And you can use that knowledge in an iterative process alongside your mechanical design to make better, faster, more stable, more robust robots.

Now, I'll admit, this isn't really a "programming" problem. The programming for any of those things is usually pretty easy (sometimes tricky), once you know what the algorithms should be. But it really can be pretty hard to figure out the algorithms. That's the challenging part of programming, anyways.

Robot drive control is an active research area for many people doing their Ph.D.'s in Mechanical, Computer, and Electrical Engineering (and Computer Science) and people are still pushing the boundaries further and further. A cursory glance at google scholar yields tons of papers with different control methods for something as simple as skid-steer and systems as complex as mecanum (mecanum is actually really hard to do the dynamics (not kinematics) for, because if you are doing the dynamics you have to model all the wheel slip/skidding).