HELP! CommandGroup not working

[Kevin Sevcik]

At least one thing you're doing wrong is reusing Commands all over the place in your CommandGroups and such. For instance:

AddSequential(Robot::oi->canUp);

That's wrong. You can't reuse Commands like this, especially in CommandGroups. Here's the relevant code from WPILib:

void Command::Start()
{
	LockChanges();
	if (m_parent != NULL)
		wpi_setWPIErrorWithContext(CommandIllegalUse, "Can not start a command that is part of a command group");

	Scheduler::GetInstance()->AddCommand(this);
}

So once you call that CommandGroup constructor with that bad AddSequential, the command instance for your CanUp button gets a parent added to it and will no longer work because that instance now thinks it's part of a CommandGroup. So everywhere you have this design anti-pattern:

AddSequential(Robot::oi->canUp);

You should replace with something like:

AddSequential(new PositionElevator(1, true));

It's more annoying, but thems the breaks.

I'm still looking at other things. Your AutonomousInit is screwy. You're starting the ZeroElevator command in there. Twice. Commands ONLY run when Scheduler->Run() is called. It's never called in AutonInit, so that command only starts to run at the first call of AutonomousPeriodic. You've already added a CommandGroup requiring the elevator after that, so I'm pretty sure the Zero Elevator command gets immediately cancelled without even initializing.

I'm not sure about your idea for triggering commands from other commands. I've never needed to do it, so I have no idea if it will work.

My only other suggestion at the moment is to start up NetConsole, cause it gives you much more detailed debugging info and you might be able to tell what's hanging up the scheduler there.

[cbf]

Kevin --

Thanks for looking at this. Actually, pretty much all the glitches you point out we've already fixed. Sorry for the confusion about branches, but the latest is at: https://github.com/ligerbots/Recycle...tialDartmouth2.

Note that one of the orange hats at the UMass Dartmouth meet today suggested moving the AddSequentials out of the autonomous class constructors, but it made no difference. I'll probably move them back in.

There are likely more errors to be discovered -- if could only at least get our autonomous command groups to be run..

[Kevin Sevcik]

Putting kids to bed, so I can't delve deeper right now. I'll admit I was looking at things before your Friday commit so I could see what y'all were talking about. I'll try to have more thoughts in an hour or two. I'm suspicious of default commands you might be running hanging things.

[cbf]

Well here's a new data point:

All of our Autonomous Command classes had a #include "../robot.h" in them (the students can be pretty sloppy about these things). I had meant to clean this up, but you know.. more important things like actually making the program work got in the way.

Simply out of suspicion, I decided to clean these up.

Now our "do nothing" autonomous command is successfully executed, but unfortunately the ones that actually do something still never return from
Scheduler::GetInstance()->Run();

I'm guessing that there was some C++ class, possibly even name confusion.

At least this is now looking less hopeless and somewhat debuggable. The tree has been updated with this.

[Kevin Sevcik]

*blinks* how are you determining that things are/aren't running at 9pm at night? Are you running your code on FRCSim?

[cbf]

Test Bot sitting in my basement.

We bought two of the new control systems. One is on a standard AndyMark kit chassis that's similar enough to the real robot to run our production code (with a bunch of run time checks -- like (if (RobotMap::testBot) ...) for all the stuff that's missing (mainly our elevator, which we try to simulate).

The test Bot is failing to run the autonomous just as well as the real bot..

[cbf]

Btw, it's 11PM here.. East Coast. And I'm checking out for the night. Maybe it'll be clearer in the morning.

[cbf]

We fixed it. No time for full explanation now, but needless to say, it's my opinion that key confusion in SmartDashboard Put commands should not set up a condition that disables the robot..

I'll post more details, and maybe make a small repro case if people are interested.