Quote:
Originally Posted by Dave Scheck
I would agree with this to a certain extent.
I definitely think that teams that have hybrid/autonomous robots that just sit there are doing so because of a lack of software understanding. However, I don't think this is the fault of the control system. I do think this is a problem with a lack of resources/tutorials that help rookie teams out. Yeah, I know there are some good ones floating around, but that isn't made public through FIRST. Most of the time the only way you come across those is here on CD, but how would a rookie team know to look here unless they were given the heads up? We based our software this year on Kevin's revamped default code. Was the default code download location even made public? I don't remember seeing an announcement anywhere.
While I still contend that graphical programming approaches still aren't for everyone, I do think that it allows inexperienced teams to have a pretty good foothold. My only hope is that they use that knowledge to jump into text based coding to get the experience.
If this problem is to be fixed, we don't need fancy new hardware or programming interfaces. The way to fix this is with education. If there was a curriculum that was provided to any team that requested it, I think that teams might find that there isn't a whole lot of magic in the programming itself...as with mechanical systems, it's all in the design.
Also, I've seen a lot more teams moving than in years past. I have a feeling that it's because there is an easy objective to accomplish (i.e. driving one or two lines) that teams aren't overwhelmed by (i.e hanging a tube on a randomly located post). 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 totally agree education is vital in any steps we wish to take. But, there are steps we can take to make sure that control is in place before the education takes place.
A major problem I see students struggling with is not in logic development, but rather in nitty gritty low level mechanical interfacing issues. They seem to grasp what the robot needs to do, and usually can come up with a pretty good implementation. The problem is the mechanical systems are lacking, and there is no easy out of the box solution to make up for this. One big example is the "my robot doesn't drive straight" issue. Teams are forced to spend alot of time tuning their robot to drive straight (most of the time without using feedback) before they can accomplish higher level goals. Usually these teams have about 27 minutes to test software before the robot is shipped, and are flustered while trying to work at the competition.
Now what if we had a system that could do dynamic simulation or object oriented design so that teams could drop in a "drive straight" module and test it before they hit the real hardware? Then could we get to the real logic based issues?