2015 Beta C++ - Help me Help YOU!

[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.

[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;

[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.

[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

[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.