Quote:
Originally Posted by Greg McKaskle
If teams were trying to use them, it would be helpful if the WPILib sensors and actuators were had support for the advanced types built in.
Any other input as to whether this would be a useful feature? Do you think it would encourage more/better sensor integration? More/better autonomous?
|
This feature is bad because it would use engineering time that ought to be used to fix real problems.
-WPIlib C++ code is flawed. There are places where it may dereference a null pointer. There is a function that takes a lock, looks up the address of a global variable, unlocks, and returns the address. If you're interested I can post a more detailed list of problems.
-The low-level interface is undocumented. This means that to bypass WPIlib requires guesswork about what the field requires. And when people ask for the documentation they're asked to take a hike:
https://decibel.ni.com/content/thread/17785
-The tool chain is out of date. It looks like some people are trying to fix that:
http://www.chiefdelphi.com/forums/sh....php?t=116921; it would be nice if something like that was available out of the box.
-Problems go unfixed for years. Here's one from 2011:
http://www.chiefdelphi.com/forums/sh...ad.php?t=89255. It does the same thing today. If the file to download doesn't exist then the error message is "IO Error while downloading program to robot" rather than "File not found at path [insert path here]".
I think it's fun to add features too but I think there are bigger fish to fry.