HELP! CommandGroup not working

[jfitz0807]

Our mechanical team is currently working some repairs so I can't try executing a commandGroup from a button. I will try as soon as practicable. That's a great suggestion.

Charles (CBF) has our Test Bot at home. I am still at the venue.

[otherguy]

For you auto modes, all the addSequential calls that you're making within the robotinit function should be made directly within the CommandGroup classes that you have in the Command package.

The commandgroup comments in wpilib for the addsequential function state that calls should be made in the constructor of the CommandGroup. I haven't gone through the source code to see why exactly, but if for nothing else it helps keep your code more organized/readable.

[jfitz0807]

We had tried that first, but it was giving the same behavior. We were grasping at straws. The Orange Hat guys here thought it was worth a try so we gave it a go.

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