What is command-based programming in C++ and how is it difference from the “normal” C++ programming? Is there any other type of robotic C++ programming? Sorry for such a basic question, it is my first year doing programming for First, and also first year doing C++. Thank you
Command based programming specifically refers to using the wpilib Commands library to handle different subsystems on your robot. I would suggest you take a look through here. This site will tell you pretty much everything you need to know. It is still “regular” C++ programming, it is just a matter of implementing a library to handle multiple subsystems and actions on your robot.
Agreed.
In WPIlib for C++ and java, there are three available programming paradigms:
-
Sample Robot: pretty much straight stick C++/Java with device driver library objects, and the safeties to keep you from using the actuators when the robot is not enabled and watchdog timeouts. The programmer is responsible for all looping and timing and so forth beyond these. There is no built-in way to break up the programming among multiple sub-teams; you will likely want to do this yourself unless you only have one or two programmers.
-
Iterative Robot: An iterative routine is called repeatedly based on your run state, but it is still up to the programmer to share time among the various tasks and link user control actions to robot actions. Again, no built-in support to keep multiple programmers in separate files and work spaces.
-
Command Based Robot: A real object-oriented infrastructure which even makes actions (commands) into objects which start, proceed, and stop by method calls. If you’ve done a bunch of programming, this one may take a bit longer to get the hang of, but it is definitely easier to implement complex flexible actions with CB once you do. It’s also offers a straightforward way to break the programming into several small teams (or individuals) each working on a subsystem (e.g. drive, pickup, shooter, climber) and its commands.
Note: in each of these, there is NO built-in protection against infinite (or just too slow) loops [such as interrupts]; it is up to the programmer to ensure that methods return promptly.
It’s pretty easy to break it up. You just need separate classes for each component. We did it quite successfully in 2014. Here’s the code for that. Also, SampleRobot is on track to be deprecated for 2018.
In 2018 they’ve added a new style as well called PeriodicRobot. It’s essentially iterative, but with precise delay times.
That is interesting. In the past command based ran on top of iterative. Will we be able to run command based on top of either iterative or periodic in 2018? I hope so. There was no hard dependency between command base and iterative that I can remember but I am away from any wpilib code right now.
Thanks,
Steve
You are correct, there is no hard dependency. You can call the command-based scheduler from wherever you want.
Thank you. This is very good news. We will be looking forward to trying commands on top of periodic.
Steve
It’s called TimedRobot
[/li]
I certainly didn’t mean to say you couldn’t do it yourself, just that you would HAVE to do it yourself if you wanted it.
Good News here, too! We would have used this a few years ago to simplify one of our auto-targeters, and we may do so this year.
TimedRobot probably fills a majority of the sampleRobot use cases. I suppose that if you REALLY need sampleRobot, you can just never return from a periodic function?
Thank god.