Do you think it’s necessary to have two drivers for Tower Takeover? If so, what are the benefits?
It fully depends on the robot and additional features.
If there are enough extra functions, such as shifters, some complicated indexing system, etc., then it would make sense to have a second driver to focus on that stuff, leaving the main driver to be as efficient as possible with main controls.
For example, last year my original shooting mechanism had an angler on it, and, in addition to automated targeting code, I also programmed in a bunch of manually activated shooting positions. To do this to its fullest potential, I had to have a separate controller with only shooting position buttons.
I never actually compete with this design (my premiere event was cancelled due to weather and I promptly redesigned), so I can see the flaws of the system.
A huge drawback to having two drivers is that they always have to communicate and be in sync. Additionally, both drivers have to be present for driving practice and skills runs, which may be easy for big teams, but on smaller teams where everyone has a bunch of jobs, that can be difficult.
TL;DR: It totally depends on a robot-to-robot basis. But the robot in question does have to be significantly complicated enough to justify a second driver, otherwise the bot’s functions will end up (even slightly) disjointed and out of sync.
7 Likes
I believe that for most robots there should be one driver. They should be able to control the drive, intake, and lift. They can have some driver auto functions, but that’s where I think a secondary driver would come in.
3 Likes
One word. Macros
Just program the complex functions of a second controller into a button. Also an amazing idea (I forget where I saw it but I’m not gonna try to take credit for it) is a shift key. When 1 button is held down, others do different things.
6 Likes