Quote:
Originally Posted by cgmv123
I think you're forgetting advanced functions, speed and customization for advanced teams. It can't be so simple that advanced teams can't take their robots to the next level.
|
I'm glad you brought this up. While there is a need to support advanced functions, there is also a limit to how far you can go reasonably.
How many teams actually use the second digital sidecar? What about the second solenoid board? How many use a solenoid board at all? Could you replace the solenoid board with Spike relays and be just fine? If you were to remove support for the second sidecar entirely, how many teams would actually be affected, and would it be an issue which they could not possibly work around?
What about the software end? How many teams actually use the DMA functions in the FPGA? What about the vision processing - Do we really need to do this on the cRio? What percentage of teams found that to be a good solution this year?
Think of all of the teams that did it the "easy way", and used the default dashboard to see the camera image, then added tape to their computer screen to indicate where the target should be. They outnumber the teams that actually did the processing on the cRio, since it was so hard to do reliably without disrupting other systems.
In my programming experience, an experienced control systems programmer can do advanced things with very little framework, given a few key attributes exist:
-You can rely on a deterministic execution timer - It is acceptable to skip this rule if you have a reasonably accurate idea of the actual iteration time, and the execution time isn't too large (anything under 30ms should be fine for FRC applications).
-You can rely that the data given to you is valid OR you can validate this data in some way (if a missing/ejected cRio module can cause valid but old data to get to the user program, it is impossible to detect and thus a failure of this requirement)
-It is assumed that raw read/writes of the IO is available (e.g. must be able to sample all inputs at the execution rate, and set all outputs at the execution rate), as this will be used by inexperienced programmers as well.
Having worked in the "other competitive robotics league" of VRC and used both EasyC 4 and RobotC 3 (the Cortex versions, respectively), I was rarely faced with a limitation imposed by the (very limited) programming environments. In particular:
-RobotC did not have the timed task structure that EasyC had. I could take delta_t and use it to adjust the wait, and that was accurate enough (plus I could use delta_t to compensate for any execution time errors).
-EasyC failed to directly tell me the state of the field (e.g. Enabled/Disabled/Autonomous), as it had a funny way of calling and terminating functions. I found that this violated the third rule, and this was my primary cause for switching to RobotC.
-RobotC language did not allow pointers in any form. This was limiting as most of my math library relied on passing pointers to functions for operating, but I resolved it.
The cRio currently does this:
-In LabVIEW, an RT task meets the first requirement above while consuming an exorbitant amount of CPU resources in the process. This is fine, but the other inefficiencies of LabVIEW push the CPU load through the roof. A normal task fails the first requirement, but like RobotC, we know the timing so we can compensate (and it's generally acceptable, although the timing of LV is much more unstable in non-RT tasks than RobotC).
-The last time I checked, it fails the second requirement above if the module comes out of the cRio after boot, as the FPGA calls return the data that existed when the module was removed (in our case, it ejected itself from the cRio while crossing a bump). I do not know if this has been fixed lately, I haven't checked.
-It passes the third requirement.
This illusion of more functionality (and the larger processors to go along with it) often just adds to the complexity of the system on whole for marginal gains. While marginal gains are good, the marginal gains in performance seriously affect the usability to new teams, and, to me, that is worse than a very simple system which reliably performs the "easy task" and forces teams to do live within the limits of the system to perform the advance tasks. While I'm not saying the old IFI PBASIC system was good, the PIC based system solved most of the advanced functionality issues the PBASIC one had, and was reliable and it booted fast. An IFI system with a small ARM user processor like the Vex Cortex would be amazing
You should never compromise the base functionality in search of advanced features. Ever.