View Single Post
  #83   Spotlight this post!  
Unread 03-04-2008, 12:51
Jeff Waegelin's Avatar
Jeff Waegelin Jeff Waegelin is offline
El Jefe de 148
AKA: Midwest Refugee
FRC #0148 (Robowranglers)
Team Role: Engineer
 
Join Date: Aug 2001
Rookie Year: 2001
Location: Greenville, TX
Posts: 3,132
Jeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond reputeJeff Waegelin has a reputation beyond repute
Re: 2009 Control System Possibility?

Quote:
Originally Posted by Tom Bottiglieri View Post
In FRC now, I see a bunch of teams who have decent mechanical systems and module level code written, but no glue to hold them all together. If we can start pushing interfaces rather than low level implementations, we get two birds with one stone. (Software design experience and competitive robots). This is the same argument I used with my team for buying AndyMark shifters over using our own. Yeah, sure, we can spend a lot of time designing an OK gearbox, but we can also spend less time designing a ROCK SOLID interface for the AM gearbox, and then focus more time on other functions and practice. Which seems better to you?
This is a very interesting way to look at the software, and one that I had never really considered before. Being mostly on the mechanical side in my FIRST (and my non-FIRST) career, I am a huge proponent of using pre-made components to simplify mechanical designs. Things like AndyMark gearboxes, IFI wheels, and even the kitbot frame can be used to take the focus away from basic building blocks, and towards the construction of more complicated and innovative systems. If we can do it with hardware, why not with sensors and software?

A great example of this is what my team went through with our software. We had plenty of time to work on development, as most of you probably know Even so, we spent about 2 of the 3 weeks trying to get our gyro, encoders, and other sensors working the way they should. Old versions of default code, missing documentation, and sensors that were ill-suited to our application all conspired to take time away from our high-level software development. By the time we figured out what was really going on with the low-level stuff, we were down to the last few days, and never did manage to get some of our fancy programs working. If we had some building blocks to work with, all of that troubleshooting time could have been spent elsewhere, with great results.

At one point in time, FIRST rules forced a great focus on low-level development. Additional-parts lists, the SPI catalog, and the Kit were all you had, so any advanced systems required pretty extensive engineering and fabrication resources. When FIRST opened those rules up in 2003, they raised the bar, and opened doors for all kinds of mechanical building blocks to help teams compete. It's time that we did the same thing for the controls side.
__________________
Jeff Waegelin
Mechanical Engineer, Innovation First Labs
Lead Engineer, Team 148 - The Robowranglers
Reply With Quote