Command Based Auto - Windriver C++ Having trouble to add sequential auto commands

[dougwilliams]

Adding a bit of info to to the above post (I'm one of the mentors on the team)...

It seems to be some sort of scheduling issue. I would have expected the function call order after enabling autonomous from a power turn on to be (roughly):

Robot.cpp -> DroveBaseSub -> AutonomousCommandGroup -> DriveAuto

And each call to DriveAuto (a drive forward, left, or right step for some amount of time) to finish execution before going on to the next step. But, it calls the constructors of all the steps of the command group and then seems to jump to executing the last step in the sequence.

Additionally, it seems run the default DriveBase Susbsystem command (which is our main teleop drive function - reading joysticks and moving the robot). So the real autonomous step is being called periodically back and forth with the default command which are most likely in conflict with what they are command the mech_drive function to do in ping-pong fashion.

I did not expect the default command to get called at all during autonomous.

Those assumptions are based on how we had last year's code - which may or may not be valid. We have also looked at some other team's command based C code and not found any differences in their structure of autonomous calls.

[RufflesRidge]

Originally Posted by dougwilliams

Additionally, it seems run the default DriveBase Susbsystem command (which is our main teleop drive function - reading joysticks and moving the robot). So the real autonomous step is being called periodically back and forth with the default command which are most likely in conflict with what they are command the mech_drive function to do in ping-pong fashion.

This part is easy. There is no "requires" statement in your DriveAuto command which means there is nothing to tell the Scheduler that DriveAuto and your default command for the DriveBase should not run concurrently.

The other issue didn't jump out at me right away and I don't have time at the moment to dig deeper. I'll see if I can get some time later to circle back.

[KPSch]

It looks like you're using the WPILib Timer to control the elapsed running time of your DriveAuto commands. Looking at the documentation for Timer, the resolution is in milliseconds (1000 in a second). In AutoCommandGroup.cpp, you're passing in values of 0.3. If this is supposed to be 1/3 of a second, try changing these values to 333.

For safety's sake, always be ready to quickly disable your robot when testing this kind of code in case it actually tries driving for 333 seconds in one direction or another.

[dougwilliams]

Originally Posted by RufflesRidge

This part is easy. There is no "requires" statement in your DriveAuto command which means there is nothing to tell the Scheduler that DriveAuto and your default command for the DriveBase should not run concurrently.

That was correct - adding requires prevented the teleop portion from running.

Still debugging why it jumps right to the last command in the sequence:

Originally Posted by KPSch

Looking at the documentation for Timer, the resolution is in milliseconds (1000 in a second).

What documentation are you seeing that in, please? Finding good WPILIb documentation is difficult. Looking at WPILib Timer C Code, it specifically mentions seconds. In the code we have it print the timer value each iteration through the DriveAuto call, and it increases between .1 and .2 (seconds) each time. The robot stops after .3. In actuality, I would say it moves for about 1 second.

What I'm thinking is that the separate calls to DriveAuto aren't being treated as "new", and unique, and each constructor is overwriting the previous calls and it effectively only acts on the last.

The prints seem to corroborate that, I'm just not sure why that would be now...

[KPSch]

Originally Posted by dougwilliams

What documentation are you seeing that in, please? Finding good WPILIb documentation is difficult. Looking at WPILib Timer C Code, it specifically mentions seconds. In the code we have it print the timer value each iteration through the DriveAuto call, and it increases between .1 and .2 (seconds) each time. The robot stops after .3. In actuality, I would say it moves for about 1 second.

I found two different sources and they conflict. One says milliseconds, here: http://users.wpi.edu/~bamiller/WPIRo...$@#$@#$@#_timer.html. I'm guessing it's incorrect. The other source I found was here: http://amhsrobotics.com/oldsitev3/wp...8h_source.html.

The best place I've found (sortof) documentation is inside WindRiver itself. Hold down Ctrl while clicking on a class name and it will take you to the header file. It does, indeed, look like it's in seconds.