In addition to mapping out the interactions that will take place during the match also sequentially map out what should happen during each autonomous. If you just start coding you're going to end up commenting out a bunch of stuff that you thought you were going to use but ended up not needing (see Steamworks code as an example of this…). It's a lot, but it will make it much more simpler to code. If using object oriented programming, each relationship ('IS A', 'HAS A') should be clearly marked as should what methods each component calls and where they are called. I prefer flowcharts as they provide a nice hierarchy to work with. Once you know what needs to be programmed, the code should be planned out. For example, shooting a small ball into a small goal (like in Steamworks) could necessitate some sort of vision processing to align with a goal while shooting a ball into a wide goal like in Aerial Assist might not require such vision processing. These discussions should give a good sense of how difficult it will be to program specific parts of the robot and are a good indicator of how much energy should be spent programming. Where should we put a camera and how many of them should we have?

Where might vision processing be useful if not necessary?

What sensors should we have and where should they be used? What are our subsystems? How should the interact with each other? Here's what you can do before the full robot is accessible to the programmer:Īt the beginning of the season it's important to figure out how the robot should be programmed to best implement the strategy that the team has chosen to pursue.

While it is very important to have the programming done before the robot is done, it is also important that there is ample time to test all the sensors, autonomous, and everything else, while still having enough time for driving practice. On this team, that's not much of a problem because a lot of our testing is done with speed controllers which have to be programmed before the whole robot is done. It's a programmer's worst nightmare (or second worst, we'll get to the worst one later).ĭon't let this happen to you you have to start coding before the robot is done.

The stress is mounting and then suddenly some mentor or head builder plops the (almost) completed robot down in front of you and says, 'OK, let's see autonomous'. The builders are racing to scrap together a ball intake that actually works and you still haven't had time to sit down with the robot to write your code. Imagine this situation: The build season is coming to a close.

First robotics labview tutorial