|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
#9
|
|||
|
|||
|
Re: Releasing software before kickoff
So the questions I saw were ...
Why not release SW earlier? Why does WPILib keep changing? and Why isn't there default code? The first question is really one for FIRST. They choose to have a kit of parts and it includes software. Sometimes they tell you what will be in it, other times they want it to be a surprise. As mentioned, Java was put up early, others were not. I don't think there is a simple answer. The second question I can answer directly. It is changing to try and make it easier and more effective for the FIRST competition. WPILib is not meant to simply be a few wrappers above the FPGA. It is that and much more. By mapping measurements to engineering units, it allows for more direct comparison to modeled and theoretical estimates. It includes vision and other libraries that have nothing to do with the FPGA, and it attempts to organize the code into a framework useful for a large number of programmers of varying capabilities. From my point of view, it is changing very little. The refnum registry in LV is an optional part. It adds overhead to avoid clusters and connector panes. It lowers the bar for using the framework, but is optional. SmartDashboard is optional. Except for error handling deep within the libraries, little changed to the LV library this year, but still, there were improvements. Java and C++ changed to add commands and RobotBuilder and LV integrated simulation. These were intended as enhancements, not as major rewrites. An additional answer to the second question is ... it gives returning teams something else to learn. This is a design competition, and in my mind, it should offer opportunities to learn new stuff and appeal to new types of people. The answer to the third is also pretty easy to explain. NI, WPI, and members of FIRST all agreed that building a robot without needing to programming wasn't a requirement. Neither is building one without having to wire or having to use nuts and bolts or fasteners of some sort. As a quick comparison, even FLL teams program. They don't even have a framework. FRC teams are clearly capable of installing one of the tools and building the default code, even making small changes to channels. True, there are faster ways to do it, just like it would be faster without nuts and bolts and without having to wire. Providing a binary version to ftp to the controller is clearly not hard, but it deprives exposing teams to a major aspect of the robot. As I"m reading my post, it comes off a bit stronger than I'd intended. I look forward to hear other's perspectives on how to make the SW be more inspiring. Greg McKaskle |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|