Awesome, I'm glad I did this correctly. I'm looking forward to using this approach in the build season. Now I need to start teaching the other programmers how to use it. This will definitely help us be able to have more people working concurrently.
Quote:
Originally Posted by Jalerre
The only suggestion I have is to set constants labeled PWM1, PWM2, DIO1, DIO2, etc in your Robot Map and then set your motor controller and sensor variables to these constants. It makes things a lot easier if wiring changes in the future and increases readability.
|
That's a good idea! I hadn't thought about doing that before, but it will definitely help with the problem of readability.
Quote:
Originally Posted by lethc
I think you'll really see why command based is great when you put in your autos - it's really easy to string together autonomous routines using the commands to control individual subsystems.
|
Yeah, that was the part that really intrigued me the most when I first looked into command-based was the easier ability to create autonomous routines, especially without repeating myself.
One other thing I just wondered about is how people manage workflow with multiple programmers. My team uses Github a lot, but we have not really dealt with multiple people working on the same project at the same time. My initial thought was to have people create their own fork and then send pull requests when their code is ready to test on the robot. Then the head programmer (me) would merge their pull requests and incorporate their new commands and subsystems into the Robot and OI files. Thoughts on this system?