
11-02-2010, 12:34
|
|
Steve Miller-Coach-Team 3355
AKA: Steve Miller
 FRC #3355 (Bigg Redd)
Team Role: Coach
|
|
Join Date: Jan 2010
Rookie Year: 2010
Location: Arlington, Texas
Posts: 141
|
|
|
Re: The increasing amount of pre-canned code
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.
Quote:
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.
|
|