|
Re: Making autonomous accessible to all teams
Folks - I don't want to turn this thread into a navel-gazing session; but...
It is obvious from the honest reports in this thread that "autonomous" is both easy and hard. So that means that "autonomous" isn't really what you should focus on. There is something more fundamental to be uncovered and discussed.
Apparently "Making autonomous accessible to all teams" is a useful title, but it steers the conversation just a bit in the wrong direction; and that bit is an important one.
For any team or individual that finds writing, integrating, testing and refining autonomous code for their FRC bot easy, we need to figure out what differences exist between that team/individual, and teams/individuals who find it hard.
Once those root causes are identified (and it is likely to take some digging to get past superficial differences and get to the true roots of the differences) then we will be ready to create a new thread entitled "Changing ___ in order to prepare each team to do well in autonomous".
To those of you who are contradicting your bright and eager, but frustrated, colleagues by asserting that "autonomous" is easy; you are missing out on a chance to be good mentors.
Obviously a blanket statement that autonomous is easy, or that library XYZ or tool abc is easy to use, is at least partially wrong. Honest, bright, well-motivated people are telling you that they are having problems; and I'll assert that they represent a non-trivial fraction of the intended users.
The brainpower contributing to this thread needs to have a dialog that gets to the roots of why some/many people and team aren't being successful, and then give advice to the tool suppliers for improving the tools, and also give advice to tool users that will get them past their roadblocks so that they can become successful with the current tools.
If autonomous is simultaneously hard and easy, then just talking about "autonomous" isn't going to be a complete discussion. Let's dig deeper and find out what is really causing us to fall short of our goals.
Blake
__________________
Blake Ross, For emailing me, in the verizon.net domain, I am blake
VRC Team Mentor, FTC volunteer, 5th Gear Developer, Husband, Father, Triangle Fraternity Alumnus (ky 76), U Ky BSEE, Tau Beta Pi, Eta Kappa Nu, Kentucky Colonel
Words/phrases  I avoid: basis, mitigate, leveraging, transitioning, impact (instead of affect/effect), facilitate, programmatic, problematic, issue (instead of problem), latency (instead of delay), dependency (instead of prerequisite), connectivity, usage & utilize (instead of use), downed, functionality, functional, power on, descore, alumni (instead of alumnus/alumna), the enterprise, methodology, nomenclature, form factor (instead of size or shape), competency, modality, provided(with), provision(ing), irregardless/irrespective, signage, colorized, pulsating, ideate
|