2015 Beta C++ - Help me Help YOU!

[tr6scott]

TORC was selected as a 2015 Beta tester for the C++ language. The odd thing about that statement is that we have never done C++ programming in the past, we are/were (too soon to tell) a Labview team. In our application to be a beta tester, I promoted the idea that this opportunity may be of value to the beta test program to get feedback from a "rookie" team perspective, but still have a commitment from a team that has been around a few years, and striving to improve.

Over the last 5 years, I have, and the team has, benefited from great support and sharing of code here on CD. I am not a programmer by trade, but a controls engineer, and typically program in PLC relay logic, as opposed to any formal language. I typically learn, by "reading" others code, understanding the logic, and then using that to explain the control algorithm, and ten have the students write the code and debug. In the Labview we have benefited most by the work shared by the Killer Bees.

Over the last two weeks, I have been trying to gain some the same understanding of the C++, language and environment, so that when we get are kits I can try to stay a couple steps ahead of the curve. I have two strong programmers, 1 in C++ (non-FRC) and one in Labview.

Our 2014 bot is fairly simple, so I think we will be able to get the teleop running on it in a few weeks after we are wired.

What I am asking for from the existing C++ FRC base, is the reference materials, best practices, code examples, documentation on coding a FRC robot. I have found somethings online, but many times, after spending time reading and getting into the information, I find out it does not apply.

So below is the list of things that we would want to implement on our 2015 bot in C++ to be competitive with our skills in labview.

Again, you don't have to write, or explain the answer, but feel free to, just post a link, point to an article, etc., I will do the work, point me in the right direction.

1. Debugging C++ code on a bot, How to doc. I know this will change with going from windriver to eclispse, but we are trying to debug C++ code and I know there is small problem in the state machine for the ball pick arm, and shooter. Right now we are using the smart dash board to watch the states via a variable name. Is there a way to "see" the code running on the bot, from the IDE? I read something about "breakpoints" we have not tried that yet. Is there a C++ equivalent, to running the "robot main.vi" from the programming terminal in labview where you can probe "real" time data and see code running.

2. FRC base framework, is there a C++ equivalent, with the control "while" loops set up for auto, tele, and perodic tasks.

3. Some of the code online says it was built with robobuilder, what is that, and what is it's function.

4. Loop timing, in labview parallel tasks, and loop timings are pretty easy, what is the structure, that insures as 20ms loop, runs in 20ms? Is there? In labview we shortcut pid gains without out the "delta t" variable, as we set the loop timings constant, is that not an option in c++

5. What are the good C++ teams, and where do they share their code?

6. Autonomous scripting, who has implemented a basic C++ scripting command set.

7. Vision example, We have never used vision on a production bot, we have played with it in labview. Is there a C++ tools set for vision, what is the best practices.

8. Data Logging, on our labview bot, we log a slew of status, and control states, to .CSV file on the cRio 10 times a second. This tool, has been a great help trying to figure out what is happening when things go bonkers. (tech term).

Thanks for the help with this, looking forward to be able to help the community as the C++ rookie team.

[Jon Stratis]

We're an Alpha team (now Beta), and can probably help out a bit.

1. My team usually just uses print statements and looks at the logs as the robot runs. This works especially well when you first load code from Eclipse, as it prints everything right to the console as the robot runs.

2. What you're looking for is WPIlib. That's what all C++ teams (WPIlibj for Java teams) have for their starting framework. It has simple robot, iterative robot, and command based robot systems starting points. When you first create your project in eclipse, you pick which one you want and the project gets built with all the default files in place - all you have to do is open them up and fill in the functions! Obviously, sometimes it can be useful to create additional classes as you go

3. I'm not entirely sure... maybe this is just a reference to the built-in project creation modules in eclipse? Creating a project worked almost identically as it used to.

4. Honestly, we've never worried about loop timings. We've used the command-based project for a few years now, and it all just takes care of itself.

5. We're a java team, although we do have a C++ version of our robot code from Alpha testing - Java wasn't quite ready when we got started last fall, and we wanted to get something running!

6. Auto can be as simple or complex as you'd like - it's just like programming teleop, except now the values you send the controllers are hard-coded, not coming from joysticks.

7. There is a vision library for C++, and for Java as well. your best bet is to just play around with it and see how it works!

8. you can do data logging the same as you did in labview, it isn't really all that difficult. C++ has native file IO libraries that'll let you create, read, and write to files.

If you have questions our programming team can help with, please let them know through e-mail! 2177 (at) therobettes.com

[Jefferson]

I don't have time to get to all your questions, but I'll touch on a couple that caught me eye.

Robot builder is a program created by WPILib to quickly create the basic structure with a lot of the objects instantiated for you. It's distributed with WPILib. Look in the Windriver folder. We've used it for a couple years and really like it.

I'm not sure if we are a "good" C++ team. We only have one professional programmer on the team, and he isn't always deeply involved with the robot code. We use him to figure out all the other difficult stuff (thanks Aaron). We have used C++ sine 2009, and you can see several of our examples including one command based robot on our GitHub site here:
https://github.com/FRCTeam16/

[connor.worley]

I wrote a lot of code for 1538 last season, and we released it here: https://github.com/TheHolyCows/1538_2014_Release

Somes notes about the architecture are in the README. Also, check out CowLexer for lexing autonomous scripts - you can write your own finite state machine to parse the tokens it gives you. PM me if you have any questions about our code.

Inheriting from IterativeRobot will help you hit the timings you want. It gives a 100hz loop by default IIRC.

[RufflesRidge]

Originally Posted by connor.worley

Inheriting from IterativeRobot will help you hit the timings you want. It gives a 100hz loop by default IIRC.

By default Iterative robot runs synced to the DS packets (nominal 50Hz) which makes it very inconsistent.

[magnets]

Originally Posted by RufflesRidge

By default Iterative robot runs synced to the DS packets (nominal 50Hz) which makes it very inconsistent.

Have you actually measured it?

[connor.worley]

Originally Posted by RufflesRidge

By default Iterative robot runs synced to the DS packets (nominal 50Hz) which makes it very inconsistent.

This seems to contradict the docs, but it wouldn't be the first time they were wrong.

[Thad House]

Originally Posted by RufflesRidge

By default Iterative robot runs synced to the DS packets (nominal 50Hz) which makes it very inconsistent.

LabVIEW also runs it's main loop synced to the DS packets. So switching from LabVIEW to C++ that portion is timing similar.

Originally Posted by connor.worley

This seems to contradict the docs, but it wouldn't be the first time they were wrong.

Last time I used Java or C++, the Periodic loops were timed to packets getting received. You could set them to a timer though, so they might have started doing that by default.

[RufflesRidge]

Originally Posted by connor.worley

This seems to contradict the docs, but it wouldn't be the first time they were wrong.

You linked to a doc with a date of October 2008. The current comments/Doxygen for Iterative Robot are a bit different:

Originally Posted by IterativeRobot.cpp

/**
* Set the period for the periodic functions.
*
* @param period The period of the periodic function calls. 0.0 means sync to driver station control data.
*/
void IterativeRobot::SetPeriod(double period)

Originally Posted by IterativeRobot.h

/*
* The default period for the periodic function calls (seconds)
* Setting the period to 0.0 will cause the periodic functions to follow
* the Driver Station packet rate of about 50Hz.
*/
static constexpr double kDefaultPeriod = 0.0;

[Joe Ross]

Many of these are answered in the screensteps documentation: http://wpilib.screenstepslive.com/s/3120

1. Getting started with C++ > Debugging a robot program http://wpilib.screenstepslive.com/s/...-robot-program
2. As mentioned previously, there are 3 choices, described at: WPILib programming > Choosing a Base Class http://wpilib.screenstepslive.com/s/...g-a-base-class
3. Described at: RobotBuilder http://wpilib.screenstepslive.com/s/3120/m/7882
4. As described in link 2, you can choose your loop rate in simple robot, or use the driver station rate for iterative or command (or change it if you want, as described above). Setting up parallel tasks is much trickier in a text based language. Lots of things to worry about. The PIDController class creates a seperate thread for each controller. Described at WPILib programming > Operating the robot with feedback from sensors (PID control) http://wpilib.screenstepslive.com/s/...rs-pid-control The command programming model sets up a state machine to step through your commands. Between those two, we have not needed to create additional threads.
7. Described at Vision Processing > C++/Java Code http://wpilib.screenstepslive.com/s/...95-c-java-code

[connor.worley]

Originally Posted by RufflesRidge

You linked to a doc with a date of October 2008. The current comments/Doxygen for Iterative Robot are a bit different:

Yikes. We were setting up our own timing loop with SetPeriod, so we never noticed this.

[NotInControl]

We are also an Alpha Tester (Now Beta Tester). We are a Java Team, but provide feedback for both Java and C++ with regards to the 2015 control system, and have no problem helping out. Just PM me.

I suggest searching github for some of the public FRC C++ code. 254 has some old C++ code available that should be of huge help as mentioned already. You will see difference in coding logic depending on whether the team uses simpleRobot, IterativeRobot, or CommandBase Robot programming structures.

I don't mind posting the code we have already developed for the Alpha Test in C++ to a public GIT repo, I just need to reconfirm that we are allowed to do so now per the NDA we signed with FIRST (originally we were told not to post code or documentation).

Regards,
Kevin

[brennonbrimhall]

Originally Posted by connor.worley

Yikes. We were setting up our own timing loop with SetPeriod, so we never noticed this.

50 Hz is also consistent with the Java API.

[tr6scott]

Thanks for all of the responses, and I can see I am not the only one that has found conflicting info.

So much time, and so little to do, um, flip that.