|
Re: 2010 Lesson Learned: The Negative
Control System, DOGMA penalties, and the rivet/bolt heads outside of frame perimeter are my biggest. Starting from the bottom:
DOGMA penalties: During QF1 at Archimedes, our HP placed a ball on the ball return but it did not roll. He then got another ball (We scored like 3 at once), saw the other ball was stuck, and pushed it with the second ball. Both went through together, but the sensor saw them as one. We got 11 DOGMA penalties for that. (we eventually had them removed as a ref saw the mistake, but we had to talk to the scoring table about that for quite a long time)
Stuff outside frame perimeter: We almost failed inspection at Troy and MSC because of four rivet heads below the frame perimeter. A layer of velcro to bump out the frame perimeter saved us.
Control system stuff: This is going to be a long list. A really, really long list.
1. Cypress board. Talking to Greg McKaskle at CMP, he told me that around 1 in 10 cold boots the Classmate will fail to find the Cypress board and the only solution is to reboot. Shortly after teams alerted NI of this problem they found the bug involving communication with the Cypress driver, went to fix it, but FIRST would not let them roll out an update to Driver Station because it did not affect enough teams to make all teams update Driver Station.
2. FMS lock. Just plain annoying. What more do I have to say?
3. Boot times. The cRio itself can boot the PowerPC processor, load the FPGA, drop the FPGA, load it again, and launch the user code in like 5 seconds (it has to initialize the FPGA twice for some calibration things says Greg). Then, the FRC comm code has to timeout on stuff and wait for stuff all in the same thread (so it can't continue loading while it times out on stuff). THEN, the bootloader runs in a lower priority thread then the user code (sometimes preventing downloads if CPU loads are high) an can't be run until the user code is running (so you can't download while its initializing).
4. Build and Download times: This is a bug in LV RT. It is not designed for downloading and compiling of codes in such a time crunch, and is not optimized to store precompiled versions of files. Thus, every time it builds, it must rebuild the entire WPI library. Then it must re-download the entire WPI library. Almost none of the build or download time is team code. If I want to change an autonomous variable, I have to wait like 5 minutes before I can run it again if I have to do a full build and download. Back in the days of the IFI processor, I could have the code build in 6 seconds and downloaded with IFI loader in 10 seconds, then reboot and wait another 200ms for tethered comm (5s radio). This does leave us with a filesystem for storing CSV files, but that only allows a sequence of events, not calculations or dynamic re-generation of paths. Many teams have asked me during competition if I have had an issue where I can't download code, I have told all of them to use the No App switch as a workaround and to look for fast loops in their code. I can't name off all the teams that have asked me this.
5. GDC stop giving us camera tasks. (Dave, the cRio just can't do vision tracking effectively). In 2009 and 2010, the GDC challenged us to use the cRio to process images of reflective targets using the Ethernet camera and the cRio. In 2006 and 2007, the GDC gave us lighted targets and a co-processor/camera module. The old system acted independently of the main processor, so any vision delays would not carry over into control lag. Now, vision delays carry over into control lag. We did not use the camera in either 2009 or 2010 specifically because if F'd with timing enough to cause PID loops to freak out. (we did, however, use the camera dashboard this year, and that worked well).
6. Radio things: The power connection on the radio is not robust enough to handle competition by itself. This is fixed with silicone or duct tape, but still, its going to come loose if you don't glue/tape it in. Same, to a lesser extent, with the Ethernet connection to the radio.
7. Breakout boards: More points of failure. While they will never have the fully integrated solution that IFI provided us with this control system, the best they could do would be to create custom modules for the cRio that provide us with specific I/O and let us mix/match. For example, an 8-AI board that has 3-pin headers that we like, or an GPIO module that has the same 3-pin headers, or a PWM module, or a "standard module" that was required, things like battery voltage, RSC, etc. or a driver module for pneumatics (this one could also include Spike outputs). They should probably be powered off the cRio's internal supply (this would remove all that wiring to WAGO's and such, but I would live with the WAGO inputs if I didn't have the breakout boards and cRio modules and 37pin cables and DSC's. Also, a solid bolt connection would be a nice addition to the spring clips of now (we have actually had modules fall out of the cRio going over bumps, so we glued them all in, but they need a more robust connection)
8. PD board and WAGO connections: I like the overall idea of the PD board, but my biggest concern is the WAGO connections. It's not the connections themselves that bug me, but having to reach a screwdriver into the side of the module and having room to move it around to open up the connection is something I prefer not to do (its quite impossible on our 2009 robot, and partially impossible on this years bot). The 2005 integrated PD board had quick-connects from the top, a much better connection design then the WAGO's of now.
I could give lots of positives to go with the negatives, but this is a negative thread, isn't it.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
|