The increasing amount of pre-canned code

[efoote868]

Originally Posted by 1075guy

the problems I see are when the canned code encourages teams to do things that they dont have the required experience to use even the pre-canned stuff.

They might get in over their head, but that's part of the learning experience.
If something does break down, if they do fail, they will learn.
That's the point of FIRST.

You know why veteran programmers are so good at debugging code? Its because they've made a hundred times as many mistakes as the rookies. We should give the rookies every opportunity to learn, even if it means putting them at risk of "failure".

[Racer26]

Originally Posted by efoote868

They might get in over their head, but that's part of the learning experience.
If something does break down, if they do fail, they will learn.
That's the point of FIRST.

You know why veteran programmers are so good at debugging code? Its because they've made a hundred times as many mistakes as the rookies. We should give the rookies every opportunity to learn, even if it means putting them at risk of "failure".

Ok, but what gives them more learning when "failing". Failing because you don't even a little bit understand what the black box is doing, or failing because you understood the concept, tried to build it, and failed?

I'm not sure which side of this fence I really sit on. On one hand, I think WPILib is spoon-feeding a lot of the more advanced stuff that is advanced in mechanical, programming, and just general understanding of how it works, and this is both frustrating to rookie teams that don't understand it, and makes the teams who spent years perfecting a system of their own to do the same thing lose whatever advantage they'd gained through those years of perfection into the system (swerve drives come to mind here). On the other hand, I see it getting alot of teams who don't have the time, money, mentors, and other resources to develop these advanced systems up to speed.

I'm not sure if it helps or hurts, and I'm not sure if the competition is better or worse for it. It makes things different than they would be without it. I think its probably a net positive force, by encouraging teams to try an advanced drivetrain, and forcing them to learn how it works along the way, however, I can see downsides to it too.

I think there comes a line where its starting to make things too easy. I'm just not sure where that line is.

[EricVanWyk]

Originally Posted by 1075guy

I think there comes a line where its starting to make things too easy. I'm just not sure where that line is.

The "line" is the point at which we've raised the floor so high that the advanced teams are hitting the ceiling. The ceiling is pretty darned high (and the GDC keeps raising it), so I don't think we're in danger of that any time soon.

I believe students get much more educational benefit from learning the system level point of view - "What can that do, and what can I do with it?" rather than "How does it do it?". I sent my students home with a homework assignment - "Pick your favorite sensor and think of 3 ways we can use it". The raised floor will allow them to spend more time on that thought and less time on the implementation.

[Greg McKaskle]

If this is about blank canvas versus paint by numbers, that is a deep discussion. If a good mentor is there to challenge, encourage, goad, and help explain why something just happened, then the blank canvas can certainly offer the richest and most fulfilling experience. The blank canvas approach seems to work less well without the awesome mentor and support network. Arguably, the systems approach, also works far better with the mentor to fill those roles. Also, if a team chooses to go blank canvas and uses kit materials and WPILib only for prototyping that seems to expose them to the full benefits of both approaches. Some teams simply don't have the time or resources to undergo the second phase.

If this discussion is about taking the contest back to year XX when things were just right for your taste, then why not really make it challenging and design your own limited challenge within your team or region for the offseason. You know the ones where you make a bridge from pasta, a boat from cardboard, or I don't know, how about autonomous robots without ICs of any kind -- tubes for all. No need to worry about spoiling them with SW libraries that way.

If you have specific feedback on WPILib, I'm sure Brad and the other contributors will be happy to get feedback or assistance.

Greg McKaskle

[apalrd]

I like the IFI processor, it worked well at its time.
The biggest advantages to me using the cRio are that I no longer have to write lookup tables for things, as I have the power to calculate them in real time.

Working in LAbVIEW: Some of the WPIlib is nice, like integrating gyros and counting encoder clicks. Some of it is not, such as the really really really annoying fact that you must set both the forward and reverse coils of a relay at the same Set (I actually wrote a vi to set them separately, based on copied code from that Set). I would totally agree with the fact that PID and Holonomic are probably going too far. Jim (Zondag) actually didn't tell us programmers that there was a PID library, and since we didn't find it until after writing the crab-drive code, we didn't use it.

The cRio: Being a first year programmer in 2009, I probably would have never been able to code the 4-wheel independent steering code without the trig power on the cRio. It was nice to have all of the power I needed. That said, after spending 8+ hours debugging a firmware issue in the cRio this year (which turned out to be a problem in the 24vdc supply on the PD board), I would say that the cRio is definitely not as robust as the IFI system. While talking to the NI tech support, if they say "Ummm... That's Bad" then you know they must not have found that problem in their testing and aren't prepared to solve it. When a problem arises with this new system, there are so many more points of error that it's quite difficult to debug some times.

cRio boot times: They bug me. Waiting for the robot to boot is the most annoying thing there is. However, after talking to NI tech support for around 4 hours, he claims that the cRio itself boots in several seconds and then the FIRST code waits for FMS comm to timeout (25s) before loading the team code. Is this the case? If so, they could make the FMS timeout a little faster.

PID and Holonomic: They are sitting unused in my WPIlib pallate. They will never be touched. As I teach the newbees (freshmen), they too will learn to leave them alone. At least they didn't give us crab-drive code. Debugging that is too much fun for them to just hand us.

[Greg McKaskle]

That said, after spending 8+ hours debugging a firmware issue in the cRio this year (which turned out to be a problem in the 24vdc supply on the PD board), I would say that the cRio is definitely not as robust as the IFI system. While talking to the NI tech support, if they say "Ummm... That's Bad" then you know they must not have found that problem in their testing and aren't prepared to solve it. When a problem arises with this new system, there are so many more points of error that it's quite difficult to debug some times.

cRio boot times: They bug me. Waiting for the robot to boot is the most annoying thing there is. However, after talking to NI tech support for around 4 hours, he claims that the cRio itself boots in several seconds and then the FIRST code waits for FMS comm to timeout (25s) before loading the team code. Is this the case? If so, they could make the FMS timeout a little faster.

Sorry it took so long to debug.

Since the cRIO and many of the other control system are off the shelf, not specially designed for this competition, their interactions, especially when one of them is failing, is indeed something not that many people have seen. Also, the AEs are mostly new to this system too. They are familiar with NI products in normal usage.

As for the boot time. The cRIO FPGA is booted very quickly. The PPC typically boots in about ten. The bridge and other elements, the FRC specific tasks all take a bit longer. But the boot time isn't waiting for any particular element such as FMS to timeout -- no magic bullet.

Greg McKaskle

[AustinSchuh]

Originally Posted by apalrd

However, after talking to NI tech support for around 4 hours, he claims that the cRio itself boots in several seconds and then the FIRST code waits for FMS comm to timeout (25s) before loading the team code. Is this the case?

You can get a really good idea on what's taking so long to boot up by connecting up a serial cable to the cRio and booting it. The debugging that I've done using the serial port confirms Greg's claim that there is no magic bullet.

[pilum40]

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.

Originally Posted by apalrd

I like the IFI processor, it worked well at its time.
The biggest advantages to me using the cRio are that I no longer have to write lookup tables for things, as I have the power to calculate them in real time.

Working in LAbVIEW: Some of the WPIlib is nice, like integrating gyros and counting encoder clicks. Some of it is not, such as the really really really annoying fact that you must set both the forward and reverse coils of a relay at the same Set (I actually wrote a vi to set them separately, based on copied code from that Set). I would totally agree with the fact that PID and Holonomic are probably going too far. Jim (Zondag) actually didn't tell us programmers that there was a PID library, and since we didn't find it until after writing the crab-drive code, we didn't use it.

The cRio: Being a first year programmer in 2009, I probably would have never been able to code the 4-wheel independent steering code without the trig power on the cRio. It was nice to have all of the power I needed. That said, after spending 8+ hours debugging a firmware issue in the cRio this year (which turned out to be a problem in the 24vdc supply on the PD board), I would say that the cRio is definitely not as robust as the IFI system. While talking to the NI tech support, if they say "Ummm... That's Bad" then you know they must not have found that problem in their testing and aren't prepared to solve it. When a problem arises with this new system, there are so many more points of error that it's quite difficult to debug some times.

cRio boot times: They bug me. Waiting for the robot to boot is the most annoying thing there is. However, after talking to NI tech support for around 4 hours, he claims that the cRio itself boots in several seconds and then the FIRST code waits for FMS comm to timeout (25s) before loading the team code. Is this the case? If so, they could make the FMS timeout a little faster.

PID and Holonomic: They are sitting unused in my WPIlib pallate. They will never be touched. As I teach the newbees (freshmen), they too will learn to leave them alone. At least they didn't give us crab-drive code. Debugging that is too much fun for them to just hand us.

I am all for good pre-canned code for FIRST robotics...When do you think it will be available???

BC

[Racer26]

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.

[Akash Rastogi]

Are you also referring to code that teams open-source to others? Or just the NI and Labview libraries?

[Racer26]

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.

Originally Posted by 1075guy

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.

I should have emphasized when will 'good' code be available. This season has been spent developing work arounds for the WPILib code.

BC

[Racer26]

Theres nothing wrong with the WPILib code that I'm aware of... It all works exactly as advertised.

[Kims Robot]

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