View Single Post
  #15   Spotlight this post!  
Unread 27-02-2014, 00:49
Pault's Avatar
Pault Pault is offline
Registered User
FRC #0246 (Overclocked)
Team Role: College Student
 
Join Date: Jan 2013
Rookie Year: 2012
Location: Boston
Posts: 618
Pault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond repute
Re: Impressions: Command Based Robot

As others have mentioned, one of the keys to command-based programming is dividing your robot up into as many different subsystems as possible, not just a few broad ones. When you put 2 actuators which don't always move at the same time in a subsystem, you are going to run into problems. I found this especially true when I was attempting to improve the code that our old programmer made last year. One of the big features I wanted was the ability for the operator to turn on the shooter wheel before we were ready to shoot, that way we wouldn't have to wait as long once we were lined up. Unfortunately, he had put the shooter motor in the same subsystem as our complex indexing system, and so implement such a simple feature as the ability to toggle a motor on/off required a huge restucturing of our code. So I guess this is one con.

Although I am generally a big advocate for command-based. I feel as though the benefits it offers are worth the extra hassle. And honestly, it works perfectly well and can do whatever you need it to do so long as you code it in the "correct" way (although that is much easier said than done).