Command Based Scheduler Issues

[kelmalon]

We are experiencing command lag after switching from auton to teleop ONLY in a competition setting. FTA’s had nothing, and dumping the scheduler after transitioning into teleop seemed to be a temporary fix. I’m new to the new command based, I did mainly Iterative/Timed Robot when I was a student. Is there anything we can do to debug/fix these issues without rewriting the code to avoid commands?

[calcmogul]

While I was mentoring my former team (non-command based), they basically always had competition-specific wireless lag issues starting from 2012 that didn’t happen at home.

As far as I can tell, it’s just a combination of router placement on the robot and 802.11 congestion in the venue. There’s a reason no one uses 802.11 (aka Wi-Fi) in industrial real-time robotics applications. We use it because the COTS hardware is cheap and available.

To be clear, I don’t know if your issue is a software or hardware one, but there are underlying technology issues to be aware of.

[bovlb]

Can you share your source code with us? A link to something like Github would be ideal.

Are you using colour sensors? If so, how are they wired?

How are you using the ports on the radio? Can you add a photo?

Edited to add: Have you looked at your DS logs? Can you share them?

[Zagdrath]

Are you experiencing loop overrun warnings? Are there any specific error messages you are receiving? Like user bovlb said above source code would be great along with what electronics are being used.

[Starlight220]

A few things:

• can you elaborate a bit more on what you mean by “command lag”?
• have you tested with Practice mode (through the DS)?
• assuming that by “dumping the scheduler” you mean calling CommandScheduler.cancelAll() in teleopInit(), that’s the recommended behavior. The few frames of disabled mode during the auto/teleop transition might affect the way your commands run (and you might be expecting different behavior).
• others have said this, but I’ll reiterate that a link to a github repo or something with your code would make help much more effective.

[kelmalon]

Here is a GitHub link: https://github.com/Troy-Argonauts/Arthur-OffSeason/tree/7a6840618f4ee3bc15542f4c517f2d474091b865

1. After Autonomous mode (in which the robot performed fine) in Teleop our shooter was pretty much unresponsive, while the drive train functioned fine. Shooter would shoot, but several seconds after buttons were pressed.
2. Yes, it functioned perfectly.
3. Yes, that is what we did.
4. No error messages AT ALL
5. @Fletch1373 was our FTAA and didn’t see anything unusual in the DS

Thanks so much guys!

[Fletch1373]

I saw the original post and was wondering if this was the same team.

For everyone else, this issue appears to match the pattern of a command (group in this case) being delayed because another command is active and requires one of the subsystems that this command needs. I couldn’t find any obvious instance where this was the case, but we ran out of time trying to debug.

@kelmalon, I left a list of troubleshooting steps with someone on your team. Have you had a chance to follow them?

[bovlb]

In the shooter constructor, you’re setting a ramp time of 1.5s, which seems quite large, and which might appear as a control lag.

You have buttons configured to change the shooter speed at any time, but the new speed only takes effect when you call Shooter.setState(SHOOT). This might also appear as control lag.

[kelmalon]

We have implemented them, and will be testing at our next competition this weekend! Thank you for your help!