I’m not so much advocating teams building their own low-level code so much as suggesting that the more advanced libraries might be causing teams to get in over their heads, and trying more advanced stuff before they’ve had a chance to build more simple things, like a tank drive.
This year, we were blessed to have our school continue the team with leftover funds that we happened to have found, just a month before kick-off. We didn’t really have time to recruit new members like we wanted, so we ended up with no student programmers. That left myself, who is great with web programming, but completely lost with C++/Java. We ended up using Java, and the pre-canned code was a Godsend.
I think it just helps newer teams or teams with fewer resources than most to get something working, and in the case of Java, it’s documented pretty well, so we can easily fix the code if we need to. I’m the type of person that learns by editing others’ code, not starting from scratch. That’s how I learned PHP, Smarty, MySQL, etc.
I respectfully disagree. The pre-canned code actually helped us stay on build schedule as rookies. We’re still having issues with how to make the autonomous work (it doesn’t work at all), but getting the bot up, running and able to go under the tunnel/over the hump is major for us since we’re majority 9th-10th graders. We’ll take time to re-learn code from scratch when we’re not pressed for time.
I am all for good pre-canned code for FIRST robotics…When do you think it will be available???
BC
It already is, in large quantities, as part of WPILib.
This discussion was about whether or not the amount included is not enough, too much, or just right.
Are you also referring to code that teams open-source to others? Or just the NI and Labview libraries?
To a lesser extent, yes Akash. But I’m mostly referring to WPILib. I’m torn, I think its a good thing, but I also think it encourages teams to try more advanced things before they’ve gotten a handle on the simple stuff, which could lead to problems down the road.
I should have emphasized when will ‘good’ code be available. This season has been spent developing work arounds for the WPILib code.
BC
Theres nothing wrong with the WPILib code that I’m aware of… It all works exactly as advertised.
I’m seeing the original point was more about trying fancier mechanical things than teams are capable of, and less about how much code you write…?
As was already alluded to FIRST has come a LONG way. Teams now have the option to try crazy things like meccanum drive because they dont have to design their own gearboxes with parts out of the small parts catalog and program in PBasic (yup thats what I programmed my first robot in! Ever try to implement your OWN random number generator??? UGH!). Anyways, FIRST has a struggle to keep the old veteran teams excited, interested and the kids attempting newer challenges every year, while allowing rookies to compete at a reasonable level with them. The ONLY way to do that in my mind is to make sure everyone can start with something.
Back in 1997 it was common to see a robot that couldnt drive… there WAS no Kitbot drivetrain… that revolution was huge!! That kitbot allowed 1511 to come up with something fun the first year - a 6WD center traction corner omni that could drive circles around some of the veterans… that was because we already had a frame and gearboxes in our kit, so we could play with some more advanced features. Had we had to design our own gearbox, we never would have tried it. And you guessed it when the gearbox failed, we took it apart, figured out what was failing and put it back together. it was a struggle, but we learned how a gearbox worked AND got a fancy drivetrain.
I also am very much of the opinion that you learn MUCH more when you fail than when you succeed. If everything is easy, you arent trying hard enough or challenging yourself enough. Starting with the black box gives you somewhere to get running, when something stops working, you start poking around at the edges and tweaking the interfaces… when you wonder why the box does xyz instead of yza, you open up the box and look inside, and work from the outside in until you understand it. Thats called reverse engineering and its done all of the time and its how many of us gain knowledge we might never have had.
And I agree with Chris, as long as teams arent turning around and pointing the finger at FIRST for making things too hard, or “giving” them failed code, then we are all on the right track. When you start blaming someone for a “gift”, you are wrong. So what if the gift causes you to struggle a little bit, if you can try to do so much more because of it, even if you fail, if you learn from your failures, you HAVE succeeded.
In short, I’m all for anything that makes teams get creative, think outside the box and do things they might never have done before… kitbot or code-wise
I’m a mentor. I’ve been through 4 years of a good engineering school, and taken numerous programming classes.
If you asked me to program an omni drive, it really isn’t that hard. There a couple different ways of doing it, all ways that highschool team members can use where they can at least grasp the concepts.
If you asked ME to create the gyro code? The vision code? Then we wouldn’t have it.
How many teams ran gyro / vision before Kevin Watson on the IFI code?
I guess where I’m going with this is that in many cases most teams wouldn’t have working robots if you didn’t give them prepackaged code. Giving them that prepackaged code also helps level the playing field. As a veteran team we have a TON of premade .vi’s from last year - averaging filters, trigger vi’s, write picture vi’s, autonomous vi’s. Recoding them from year to year using the newer members of the team is a great teaching tool. If I were a new team? Well, the task is staggering just getting a simple mechanism to function.
Would swerve drives even be popular and well understood if we hadn’t had some pioneer teams that led the way and developed at least the concepts? How many other teams have been able to do that because of those pioneering teams and the amount of help and advice they offered to other teams?
I certainly wouldn’t have the faintest clue how to write that vision vi to track that target this year. How many teams would have managed to both write one AND make it robust? 2? 3?
So far, I can’t say I’ve seen anything that is too prepackaged. It DOES push the veteran teams further when code they’ve written and taken for granted is suddenly freely available in finished form to the other teams. Suddenly that vet team has to start all over to differentiate themselves. Not a bad thing.
Did you find it difficult to do? What difficulties did you encounter?
~
Yes, things like WPILib make programming the robot a lot easier than it used to be. Some teams would be lost without it, unable to get their robot to do anything, and by that merit alone it’s worth keeping around.
Other teams see the code that’s available, and get in over their heads because they don’t understand how or why the code works.
Yet other teams have students with the knowledge and capability to do what needs to be done without using WPILib.
The question i struggle with here, however: Is WPILib holding some kids back? What i mean by that, is the presence of such easy to use, good code getting some kids/teams so comfortable that they stop pushing their own boundaries? I think we can all agree… once you’ve written code to make the robot work one year, writing the code for the next year is a lot easier. Do teams push the boundaries, and continue to challenge their members?
This year, we had the returning members and the freshmen members on the programming team. The freshman have, so far, gotten to code the “easier” sections, like controlling the kicker (a simple on/off with a limit switch attached). The returning members got more complicated with working on the Mecanum and PID loops, something we hadn’t had need of before. So for us, everyone got to be challenged and work at the limits of their capabilities, without getting in over their heads.
What concerns me as a mentor is 3 years from now, when the freshmen are seniors, how do we keep them engaged? How do we present them with a challenge they haven’t seen before in programming? This is our teams 4 year - the first and second were filled almost entirely with seniors, making this the first year we’ve really had a strong returning team, where the returning members outnumber the new ones. As such, we haven’t had to deal with these types of problems, yet…
Are you coding PID loops in software to control wheel speed, because of the mecanum drive?
If so, I’m wondering why you chose not to use the built-in closed-loop speed control available in the Jag firmware.
I ask because our team is weighing this decision now.
Thank you.
~
As a new programmer, I find the code very helpful. There are things I just couldn’t do without it. At the same time, I still had to learn how to implement the code. This is my second year on the team - last year, we used the really simple LabView layout, which gave me a good intro to how the robot worked. This year, I used Java, which I was able to do partly from the code given last year, and partly due to the provided code, which gave me a starting point to see both how the code worked with the robot from Java and a working example to try new things on. I say I, because this year I am the only programmer on the team.
And, NetBean’s Ctrl-Shift-B (shows the source) helps me figure out exactly what it does and how, to understand it.
So, my opinion on the matter is that, especially for newer and smaller teams, that the canned code is almost necessary to have a working robot in 6 weeks.
I think Kim hit it right on the head. I just think that some teams have started EXPECTING it to be easy, and start complaining when they can’t figure out how to use the latest new widget we were given, instead of taking it apart (looking at the source) to see how it works.
They’re working on their own code. We’re well aware of the built-in control available in the Jaguar, but the challenge for implementing that is minimal. For the returning members, we would flip a few virtual switches in the Jaguar, call the provided holonomic code, and the robot would be driving. There’s no challenge, there’s no requirement to really understand how it all works, and quite frankly i think the students would get bored (i know i would) and lose interest halfway through the season when everything already “just works”.
So instead, we focused on why Mecanum drive works, how it works, what the code needs to do to make it work, what the response curves would be to make it work, etc… let the returning members create a few different implementations that may work and let the drive team test them out (with the provided code included as well) - determine which is best, why it’s the best, etc. Basically, we give them a glimpse into the development-test-development cycle many companies go through, and a chance to evaluate provided off-the-shelf software and determine why it’s the best choice (if it is).
Once that was finished, we got more complicated with PID loops, going through the exercise of figuring out why they work, how they work, implementing our own, testing, etc.
When dealing with smart, driven students, sometimes the easy, out of the box option is just too boring to be truly inspirational I say a good day for a FIRST mentor is when the student walks into the meeting and says “I was thinking about this <mechanism, algorithm, strategy, whatever> we were looking at last time, and had an awesome idea…” A bad day for a mentor is when the students are only engaged while at the meetings, and do no creative thinking outside.
Our team developed, coded, tested, and refined their own mecanum algorithm. Never even looked at the omni VI. An overview is presented here:
http://www.chiefdelphi.com/forums/showthread.php?p=916383
I would be most interested to hear what your team did, if you would be willing to share.
~