Quote:
Originally Posted by virtuald
Everything that RyanN said.
Honestly, command based programming in RobotPy is not very pythonic, and I find that it takes a lot of boilerplate to get even simple things done. There are definitely ways to address some of it -- in particular, we probably should have better support for not crashing the whole bot if one of your commands is broken. However, I don't use Commands et al, so I haven't messed with its internals that much.
This season, I've introduced an experimental framework called MagicBot that is simpler to use than command based programming and has builtin stuff to ensure that a wayward component doesn't bring the entire bot down in a competition -- but it's not quite as full featured yet (in particular, no support yet for sequential state machines like CommandGroups -- but maybe I'll do that this weekend).
The documentation explains some of my philosophy for structuring robot code, you may find it useful. http://robotpy-wpilib-utilities.read.../magicbot.html |
I'm really liking the look of that magicbot setup. It seems to be more of a middle ground and more of a python way of doing things, which is exactly where we are struggling. The kids found the way we had them coding commands/subsystems/etc to be extremely intensive due to the amount of repetitive boilerplate and frankly, led to tons of silly little errors.
I'm going to have to give this a shot on our practice bot, to see if it's worth looking at for off season training. Honestly, if it was week 3 instead of now and it tested stable, we might look at rolling it out to competition.