Quote:
Originally Posted by Greg McKaskle
During the beta period and the FRC season, FIRST engineers and NI engineers discuss the risk and impact of all bugs that are found. Some bugs are worth fixing, but others are difficult or risky to fix. Sometimes, as long as the customer is aware of it and they have a good workaround, the best course of action is to leave things alone.
This bug was deferred, meaning it will be fixed after the season is over, and when side-effects from the fix can be discovered somewhere other than your robot on Thursday before an event.
Greg McKaskle
|
This year encoders will almost certainly be used on most robots so I find it interesting that this was deferred so quickly. I understand NI's point of view (I know how you feel, I've worked in development for 6 years and SQA for 3 and I know how it's like when there are deadlines to meet) but as the end user this seems kind of like an easy fix to do. The hardware is the same as last year so it must be on the code side of things. It worked last year so there was working code before but this year it's broken so it must be a regression. Usually when I have to deal with regressions (unless code was refactored?) it's easy enough for me to do comparisons of code from when it did work to when it didn't and see what caused the issue.
Can an official help document, or something to that effect, be provided to teams? I've read through this thread and I think most of us are still at a loss on the best way to workaround this issue.
Best Regards