2009 Control System Possibility?

[Adam Y.]

Originally Posted by seanwitte

This is a point of view that has always annoyed me. How many different ways are there to write the code to drive straight or integrate the gyro? Why is it that nobody, except Kevin, steps up and actually DOES something about it? Instead of saying "I can't compete because you don't give me enough" why aren't more people publishing these solutions? This is a breakdown in the community, not in FIRST.

The answer to this problem depends on how complicated the solution is. It could range from 1 to infinite depending on what you want. Also, not every single sensor interfaces the same way and even then you can write code multiple ways to do the same thing. Not every single robot behaves the same way. Even then I still find it odd that you have to rewrite the code.

[Booksy]

I 100% agree with you(post 80) This year our team spent almost all of our time at the toronto regionals trying to fix the robot or change the programming to make it drivable(we did about 100 accidental donuts throughout the week because of our crazily un-drivable drive platform, but we managed to compete in every round) and our game layer cost a total of about $100 (made of copper tubing and pvc, this also won us the judges award) because we didn't have enough money, we didn't even have team uniforms (although that was more because of an unmotivated marketing team).

If the new control system was more expensive I can't imagine how we would manage to compete, we didn't last year at the current price.

Also, I learned C for this robot, which wasn't to bad because I am already proficient in other languages (python, java, etc.) which are similar, but I HATE easyC. I'm not sure why, it's supposed to be easy, you'd think that would be good right... however the real C code makes much more sense to me as it is not dumbed down, it is complete.

With all that being said, I would really like to see a new control system next year. We had a lot of trouble with the IR sensor. during hybrid mode the IR sensor would only except the first command or two and then take off into a wall. This doesn't really get solved with a new controller but the point is that a more plug and play version with less low level aspects would have allowed us to do some real good things with our robot other than drive, spin, crash. Isn't robotics about making things accomplish complex tasks? not making robots barely scrape by the easiest of tasks.

[adman]

Read the thread to here. Since I work with NI stuff, C stuff, Assembly stuff,
VB stuff etc etc I want to say that I haven't seen too many monkeys
writing code as was suggested earlier.

Our team used Kevins code pretty much out of the box ( or off his site ).

What you are missing is the PID knowledge to use the information the
gyro is giving you. Thats pretty heavy stuff if you want to do the
whole thing. Driving straight aint so bad.

If you aren't in a big hurry you can use one of the pre-made compass
modules that are on lots of on line vendors sites.

The only thing I wish you guys had was real time debug. No printfs,flashiing
leds. REALTIME DEBUG. FIRST PAY ATTENTION AND GIVE THE GUYS
A BREAK AND WHATEVER YOU DO MAKE SURE IT HAS A JTAG HOOK OR
REAL TIME DEBUG MODULE ON THE CHIP.

[ayeckley]

My $0.02 on the topic of "build from existing modules" vs. "design and build it from scratch":

Outside of FIRST, it's a lot less about "integration" and a lot more about "design". There are relavitely few industries in which an engineer can just order parts from a catalog, integrate them together, and have an acceptable widget. This is especially true for situations where the widget will be built in more than onesy-twosy quantities. I think isolating students from "low-level" design will give them a false impression about what the majority of design engineering is really about. I'm pretty happy with the status-quo for FRC in terms of what the teams have handed to them on silver platters (the Field Control System, Kevin Watson's templates, etc.) vs. what they have to do for themselves (figure out how to drive in a straight line in autonomous, etc.). I don't think more silver platters are necessary - mechanically, electrically, or software-ically.

On the question of "how many different ways are there to make a robot drive straight?": Lots, actually. The hard part is to figure out which ones will work acceptably well based on the design of the robot, the objectives of the robot, etc. Let the teams continue to figure out how to do it for themselves. I don't think FIRST should lower the bar so far that the only thing left is a bunch of interconnected black boxes, and too few of the students know what goes on inside them.

Someone also made the argument (I'll have to paraphrase) that in the non-FIRST world "mechanical stuff just works, and it's all about the software". My experiences in the various disciplines over the years don't support that. The opposite, actually. Software doesn't wear out. The first copy of the executable file is identical to the 400,000th copy of the executable file. Software doesn't need to be crash tested (physically, at least), vibration tested, EMC tested, UL tested, etc.

Finally, the "code monkey" thing. The root of it (despite what Wikipedia says) is the old saying "if you set enough monkeys at typewriters and wait long enough, eventually one will bang out a copy of Romeo and Juliet". I know I wouldn't ever want to be referred to as just another interchangeable monkey, so I won't use the term when referring to programmers. I think it's an insult -- self-deprecating intent or not.

[erikstotle]

Originally Posted by ayeckley

My $0.02 on the topic of "build from existing modules" vs. "design and build it from scratch":

Outside of FIRST, it's a lot less about "integration" and a lot more about "design". There are relavitely few industries in which an engineer can just order parts from a catalog, integrate them together, and have an acceptable widget. This is especially true for situations where the widget will be built in more than onesy-twosy quantities. I think isolating students from "low-level" design will give them a false impression about what the majority of design engineering is really about. I'm pretty happy with the status-quo for FRC in terms of what the teams have handed to them on silver platters (the Field Control System, Kevin Watson's templates, etc.) vs. what they have to do for themselves (figure out how to drive in a straight line in autonomous, etc.). I don't think more silver platters are necessary - mechanically, electrically, or software-ically.

On the question of "how many different ways are there to make a robot drive straight?": Lots, actually. The hard part is to figure out which ones will work acceptably well based on the design of the robot, the objectives of the robot, etc. Let the teams continue to figure out how to do it for themselves. I don't think FIRST should lower the bar so far that the only thing left is a bunch of interconnected black boxes, and too few of the students know what goes on inside them.

I whole-heartedly agree. Engineering is not about throwing together blocks of high-level code that "magically" works. If students aren't exposed to what actually goes into making things work the way the do, then what exactly is the point of even doing robotics? Anybody can throw together a program if enough of the low-level work has been done for them. IMHO the biggest problem with the FIRST program in general (just from what I've seen on my own team, but also at competitions) is that, while people are willing to get excited about engineering, when it comes right down to it, a lot aren't really motivated or open to learning. There is a lot more about programming than meets the eye. Trying to get somebody to get the hard work out of the way so you can make an even more awesome robot is not the point. I thought FIRST was not only about getting students excited about engineering, but also about actually giving them skills to get ahead in the workplace. I'm fairly sure that at a lot of companies, you won't be able to just integrate a bunch of high level components and expect it to work. Don't get me wrong, I have no problem with teams that don't have a very experienced programming team to use more high level tools to get a working robot together, and maybe learn a bit more about programming. But its a whole different story when you prevent people (myself included) who have worked very hard to get to the level of proficiency in programming, from using the skills that they have acquired. If FIRST decides to switch to a system that "dumbs down" the programming too much, then I will probably quit. I would probably gain more experience fiddling with various open source projects than I would playing around with a robot that doesn't allow me to program it at a low enough level. I want to gain knowledge and experience, not some new-fangled system that restrains me. Maybe I've very much missed the point and am all wet, and if that is so, then please forgive me, but I felt it needed to be said.

[Tom Bottiglieri]

Originally Posted by erikstotle

I whole-heartedly agree. Engineering is not about throwing together blocks of high-level code that "magically" works. If students aren't exposed to what actually goes into making things work the way the do, then what exactly is the point of even doing robotics?

Remember this is a short 6 week project meant to inspire students to study engineering. They don't need to be engineers out of high school, just pointed in the right direction.

Engineers aren't around to design mechanical systems, or to create software packages. Engineers exist to solve problems. High level problem solving is still problem solving, isn't it?

[Tim Skloss]

Originally Posted by Danny Diaz

Why the heck even participate in the competition if your end goal isn't to win?

If that simple statement were true, then only 20% of the teams in FRC would even show up to the tournaments; the rest too ashamed that they are not competitive enough.

FIRST is about the students. As mentors we show them that engineering is hard but with disciplined and steady work it can be immensely rewarding. (If it were easy, where's the satisfaction??)

They are all winners the minute they decide to get serious and start contributing to the team's efforts. The competitions are their chance to celebrate what they have accomplished. Whether they end up with a simple, complex, broken or top-tier robot will make no difference.

Teams that stress winning as the primary goal (and expect FIRST to make that easy), set the students up for disappointment when they don't achieve that goal which (gulp) may drive them away from enginering because the students go away with the idea that "it's too hard to be successful"... when in reality they are winners just for participating and working hard.

[erikstotle]

Originally Posted by Tom Bottiglieri

Remember this is a short 6 week project meant to inspire students to study engineering. They don't need to be engineers out of high school, just pointed in the right direction.

Engineers aren't around to design mechanical systems, or to create software packages. Engineers exist to solve problems. High level problem solving is still problem solving, isn't it?

That is true. I just don't want to be confined to only that. Of course students won't be engineers out of high school. I also understand that there are many different view points and situations with different teams. I just think FIRST should at least keep the options open when it comes to programming. I have no problem with switching to a new system, but I also am very afraid of the programming becoming uninteresting, per se. Then again, maybe I'm just getting overly anxious and there is nothing to really get worried about. Time will tell (hopefully)

[Tim Skloss]

Originally Posted by Danny Diaz

They can't throw us into the ocean and expect the community to teach us how to swim.

But isnt' that is one of the pillars of FIRST, at least according to Dean Kamen? FIRST requires the community of engineers to give back and inspire the next generation. The students need to see that we have an important impact on our society, and make a good living doing it. And those jobs are there for them.

[pogenwurst]

Originally Posted by Danny Diaz

Why the heck even participate in the competition if your end goal isn't to win?

Originally Posted by Tim Skloss

If that simple statement were true, then only 20% of the teams in FRC would even show up to the tournaments; the rest too ashamed that they are not competitive enough.

FIRST is about the students. As mentors we show them that engineering is hard but with disciplined and steady work it can be immensely rewarding. (If it were easy, where's the satisfaction??)

They are all winners the minute they decide to get serious and start contributing to the team's efforts. The competitions are their chance to celebrate what they have accomplished. Whether they end up with a simple, complex, broken or top-tier robot will make no difference.

Teams that stress winning as the primary goal (and expect FIRST to make that easy), set the students up for disappointment when they don't achieve that goal which (gulp) may drive them away from enginering because the students go away with the idea that "it's too hard to be successful"... when in reality they are winners just for participating and working hard.

I (personally) am not involved in FIRST because I want to win (of course, that would still be nice ). I'm involved because I want to improve my programming skills and knowledge, and I in all sincerity thoroughly enjoy the way that programming for FIRST makes me want to bash my head against a wall.

[ay2b]

Originally Posted by Dave Scheck

I definitely think that teams that have hybrid/autonomous robots that just sit there are doing so because of a lack of software understanding.

That may be the case for some teams, but I think more often than not it's due to insufficient time. When you only get the robot a few hours before it goes into the crate, in order to program it, it's usually considered more important to make it work in teleoperated mode, than in hybrid/autonomous mode.

Originally Posted by Dave Scheck

I think that the way that the game is defined will dictate the excitement of the autonomous movement (2005 wasn't very interesting was it?).

I agree with the game design dictating the excitement level, but I thought 2005 was very interesting. Our autonomous that year (after a few iterations doing other things) stacked a tetra on a goal, grabbed the hanging tetra (catching it mid-air), and then stacked it on top. 2004 had my favorite autonomous run - in one match we autonomously caught a ball mid-air as one team tried to beat us to it, and knock it out of our grasp - but 2005 was my overall favorite in terms of what we did and could do autonomously.

[seanwitte]

Originally Posted by erikstotle

I whole-heartedly agree. Engineering is not about throwing together blocks of high-level code that "magically" works.

Actually, writing software for a living is primarily about doing just that. It's too expensive and time consuming to write everything from scratch. But this is FIRST, not real life. You're still at a point where you need to learn how all of this stuff works at the most basic level. I think the rules about code re-use need to be revised to allow teams to build up a body of knowledge and expertise over time. Your first year may be ugly, but each year after that should be better.

Going along with that, what about teams that choose not to invest resources to build up their programming expertise? A team without mechanical prowess can turn to AndyMark, but there is no source other that Kevin Watson for programming help. There are scattered whitepapers and forum posts, but no real tested and reusable code. A library of solid source code would be beneficial to everyone.

[Jon236]

Originally Posted by seanwitte

Actually, writing software for a living is primarily about doing just that. It's too expensive and time consuming to write everything from scratch. But this is FIRST, not real life. You're still at a point where you need to learn how all of this stuff works at the most basic level. I think the rules about code re-use need to be revised to allow teams to build up a body of knowledge and expertise over time. Your first year may be ugly, but each year after that should be better.

Going along with that, what about teams that choose not to invest resources to build up their programming expertise? A team without mechanical prowess can turn to AndyMark, but there is no source other that Kevin Watson for programming help. There are scattered whitepapers and forum posts, but no real tested and reusable code. A library of solid source code would be beneficial to everyone.

Kevin's template provides a common base that enable's teams to have quadrature encoders and gyros running almost immediately, so you don't have to create everything from scratch. But how does a student understand how a gyro or an encoder works if they don't write and test the code themselves?

My programming training involves:

1. Having the kids read and understand Kevin's template to understand how the code works.
2. Teaching the basics of PID coding, switch debouncing and the like.
3. Trying to introduce behavior-based programming, to give the kids something to hang everything on.

Then I sit back and watch what they do. Sure I make suggestions and help them debug, but mostly I enjoy having them show me what they have done! They come away from the process with the self-confidence of having created a piece of code which makes the robot perform as they wish and the knowledge gained by doing the coding themselves. That is what FIRST is all about!

[Danny Diaz]

Originally Posted by Tim Skloss

FIRST is about the students. As mentors we show them that engineering is hard but with disciplined and steady work it can be immensely rewarding. (If it were easy, where's the satisfaction??)

They are all winners the minute they decide to get serious and start contributing to the team's efforts. The competitions are their chance to celebrate what they have accomplished. Whether they end up with a simple, complex, broken or top-tier robot will make no difference.

Originally Posted by Tim Skloss

But isnt' that is one of the pillars of FIRST, at least according to Dean Kamen? FIRST requires the community of engineers to give back and inspire the next generation. The students need to see that we have an important impact on our society, and make a good living doing it. And those jobs are there for them.

Yep, Don't get me wrong, I agree with all these statements - except maybe the part about kids not caring if they have a crappy robot or not; everybody wants to have a successful robot, but I do agree that it's all about how you measure success - a rookie team measures success very much differently than a veteran team, but should that be the case?

I also agree that engineers should be giving back, but I had better not see:

<R244> Each team shall have an engineer, or else they won't understand jack about what's going on.

In my mind, FIRST should have a competition that is accessible to kids, inspiring to kids, and FUN for kids. The engineers should be there to help those kids go farther, not for basic functionality. That's my opinion, at least. Just like there's a kit frame, there should be kit controls that are easy to use.

-Danny

[tdlrali]

First of all, this thread contains some of the best discussions I've ever seen on Chief Delphi.

The two common viewpoints here seem to be either that a low-level system is better since students learn more or that high-level is better because it allows everyone to be more competitive.

How about a mix of the two? That's what we have right now - more experienced / advantageous teams can write everything in C (which is low-level enough), and the others can use easyC/WPILib.

Of course, neither option comes with complete control logic for everything, but the basic building blocks are there - we can use encoders, gyros and the like right out of the box (ok, small tweaks are often necessary). The argument that this is not enough is not valid. Software and hardware are very similar in this aspect: FIRST doesn't ship us a complete drive base that works right out of the box - they give us frame components, gear boxes and motors, and we can figure out what to do with it.

Continuing the hardware to software analogy, if all teams were given a full drive base, would that make FIRST better? In my opinion, it would not - it would take away from the design process and frankly, it would make the robots boring. Would we see swerve drives on the field if everyone was given a full drive base? Similarly, the fact that we are not given full software blocks makes FIRST more competitive.

Now, to get back to the actual topic, how would any hardware solution affect what the software can do? As long as FIRST leaves enough possibilities (aka, the choice of either using low(er)-level or high(er)-level programming), anything is possible. I don't think that FIRST should give us full software solutions to common problems, though. Coming up with those solutions is just as important of a lesson as finding solutions to mechanincal problems.

Lastly, the community has a huge influence over what is available to teams. I know that CD is always willing to help out people asking for help, but every team needs to be aware that this resource is available.

It would also be helpful to newer teams if the older teams stepped up and released some of their precious source code. I know everyone is proud of what they achieve and does not want to give it up to other teams since they want to keep the competitive edge, but if we want to make competitions more interesting, we need to give some of it up.