Quote:
This problem will only get worse for us, and will start to affect other teams as autonomous gets more prevalent and more complicated (I'm almost certain auto mode will be back next year and
will be an order of magnitude more challenging).
|
Add to this concern the fact that, as autonomy becomes more "real," we will all need more sensors so that the robot can figure out what its environment is like.
More sensors = more time spent in the serin command, more variables, more processing of sensor inputs to condition the information.
The space for code may become a limiting factor. If you want to save cycle time by using in-line routines instead of subroutines and by using look-up tables instead of trig functions, you rapidly run out of EEPROM to store the thing in.
In the past two years, we have used up the entire variable space, including unused input bits which we doubled as scratchpad. We've been at 52 ms cycle times (which I consider is the outside limit). This year we used up all of our digital inputs. We also used 93% of our EEPROM.
We freed up some of these resources when we improved efficiency in the code. But still, we were creeping close to the boundaries.
With more complicated autonomy, we may have to limit ourselves to a drive train + lots of sensors for autonomy, and skip doing anything else.