Some issue with the autonomous

Hi everyone, There are some issues with our autonomous period. The problem is that we try our robot with 3 balls and 2 ball mode in our school with our radio, and the autonomous works great but when we try it in the real match with their configured radio, our autonomous code won’t work. Then we decided to use our working autonomous code which we used in the official regional but that code didn’t work either. We were the only team that facing that problem in the competition.

1 Like

Can you share a link to your code? If you have more than one routine, please indicate which one you’re selecting. Also, can you share the DS logs? Are there any messages in the RIO log?

I’m assuming that teleop works fine in matches.

Here is the code: https://github.com/Scorpions-Robotics/Command-Based-2022

The autonomous code that we selected: https://github.com/Scorpions-Robotics/Command-Based-2022/blob/master/src/main/java/frc/robot/commandgroups/Autonomous/TwoBalls/Blue21.java

the teleop worked fine in the match

and I’m gonna try to send you the riolog tomorrow. Thanks for your help.

What do you mean be won’t work? The robot does nothing?

Also, what do you mean by with your radio? When you are testing are you choosing autonomous on the drivers station and then enabling the robot?

If you run the command in teleop the robot performs the command appropriately? (You can temporarily map the command to a joystick button or submit it via the smart dashboard.)

Thanks. I’ll take a look when I get a chance.

One thing I notice straight away is that many of your commands aren’t declaring requirements. This means they may be fighting with the default commands.

Another important debugging thing is that it’s useful to emit a message in the initialize and end methods of every auto command. That way you can tell the difference between the command running but doing nothing, and the command finishing early for some reason.

Also, it shouldn’t make much difference, but you might want to try testing in “practice” mode instead of “autonomous”. That’s closer to what happens in a match.

1 Like

Another thing I note is that you’re calling reset on your encoders and gyro every sub-command, and calling setDistancePerPulse every execute. I’d recommend that you write your code so that methods like this are called once when the subsystem is constructed. Commands that need relative movement can simply record where they start and subtract that in their calculations.

I recommend this for several reasons: These resets typically cause CAN bus messages to be sent to the device. This results in a short delay between asking for the reset and seeing its effect. Even worse, if you have CAN bus congestion, then the message can get lost. Another reason is that it makes it easier if you later decide to add dead reckoning position tracking to your code.

I mean; in the code theoretically it must do:
open the intake,
1,5 meter go straight with intake run
turn 180 degrees
turn shooter with (3 sec wait command and turn feeder)

but in the match

open the intake,
1,5 meter go straight with intake run
turn 180 degrees
run shooter
and then the code stops
it doesn’t feeds the ball.I know it sounds weird but we don’t know what we are going to do for this situation because as i said it’s so weird problem.

for the radio, i mean that; the radio that we configurated ,not the radio that configurated in the competition and of course we are selecting the autonoumus mode on driverstation.

and i tried mapping the commands to the buttons in teleop and it worked well. Thank you for your support.

When you say the autonomous code won’t work, is nothing happening? Not even the intake deployment? Do you have video?

Your problem probably falls into one of these categories:

  1. You’re not selecting the auto you think you’re selecting. I notice alliance detection in RobotContainer, but Red21 seems identical to Blue21.
  2. The autonomous routine is terminating early. This is why I’m looking at termination conditions and thinking about resets.
  3. The autonomous routine is getting stuck on a step you expect to terminate quickly. It’s not clear why we wouldn’t at least get to drive straight.
  4. The autonomous routine can’t control the motors because something else is fighting it.
  5. Something else is eating up all the event loop time. The DS log will show this.
  6. Program is crashing. If it is, a stack trace is key to debugging.

Seeing the riolog, and having auto sub-command logging in the riolog, would both help to debug this problem. Also the DS logs would show if there was any attempt to power the motors.

1 Like

Ah, so the auto does run, but stops just before it runs the feeder? That’s key information to know.

Is it possible that your auto is taking longer than 15 seconds? Have you tried running it in practice mode?

Yes we tried in practice mode with our radio and it worked properly. Thanks for your help we will try to check the ds logs .

Here are the logs: https://drive.google.com/file/d/1F2e0SIkYN6Q5srYYt8utKuIEbPIUJE1H/view?usp=sharing

Can you look at it please :cry:? We saw some errors during the autonoumus period in our matches.

In elimination 16:1 you had a number of brownouts, probably because your battery voltage was dipping to 7V. They seem to coincide with running the four motors on your drive train. As this didn’t happen in other matches, I’d put it down to a dodgy battery.

There are a lot of complaints about button 12 on port 1, which I believe comes from this line.

There are some loop overrun errors, which isn’t a problem if it’s only occasional.

I see motor safety warnings on the Differential drive. I believe these come from the periods of autonomous when you aren’t driving, so not a concern. You can suppress that warning by adding drive.feed(); to DriveSubsystem.periodic.

But none of that accounts for your problem. I’d expect to see the shooter start just after the second drive, about 4s into the match, and then the feeder to run two seconds later. There’s no sign of either in the DS logs.

I can’t tell from these logs whether the camera is seeing the target, or whether you’re calculating a shooter speed of zero, but I’d still expect the feeder to run.

I don’t suppose you recorded network tables for any of your matches, did you? Do you have match videos?

3 Likes

I extracted a couple of charts for the auto period in Elimination 20.

The first shows PDP channels 0, 1, 14 & 15, which I believe to be your drive motors. We can clearly see two bursts of activity: one for drive straight, and the other for turn.

The second shows all other channels. We can see two small bursts of activity on channel 5 during the drives. There’s a big burst on channel 13 right at the end of auto. The remaining channels seem to be drawing a constant 2-3A throughout.

What are channels 5 and 13? Can you identify the channels for the shooter and feeder?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.