Hi,
Today we were practising our autonomous skills for rapid relay and encountered a problem. We have two parts of our code, the first part shoots in side of the goals then the other part goes to the other side of the field and shoots in the other two goals it then just repetitively drives forward, gets two balls, then shoots them. The problem we have is in this forested part of sometimes drives al the way up the the ball but sometimes only drives half the correct amount. We aren’t using our brains built in gyro as it creates problems while turning. Any help would be much appreciated.
Some code would be helpfull to se if it is a coding issue, but is sounds like your wheels are slipping.
Uploading: IMG_6813.jpeg…
Uploading: IMG_6812.jpeg…
Uploading: IMG_6811.jpeg…
This is our code, we are using a bumper sensor so the robot knows when it is aligned with the goals and can shoot, for testing purposes we have just made a loop where it repeats going forward, picking up two balls, going backwards to the goals and shooting. The first time usually works, then it drives only half the required distance a few times then just alternates every few times between going the correct amount and the incorrect amount.
1 Like
I can’t see the first three pictures, so I can’t hepl you with your issue.
Alse, Whenever you handle your robot, it must be reset to Starting Zone 2. I think what I see from the one picture and your discrption is that you are pressing the touchLED when the robot is aligned with the goal. As per <RSC8>, you would have to reset the robot. Some pictures of your robot may also help if it is a mechanical issue.
Hi, I’m not sure why the photo didn’t upload, I know that I need to put it on the starting zone but I have just made it like this when I am testing. I have tried to upload the photos again with a photo of our robot.
A lot of systems use PID to mitigate error, which would be useful, except they would be very hard to implement in block code. The default functions probably have PIDs but they’re generic and aren’t tuned for your use case.
I had a similar problem last year (over under), and I just fixed it by making a better PID.
Is it possible it’s a problem with your robot? The drivetrain isn’t squared, a motor got unplugged, something shifting weigh , etc.?
I’ve read many posts that have said that the IQ smart motors have PIDs intergrated in them (also, what OP is describing I don’t think this would be the issue). @jpearman could you clarify this?
I think this is hte most likely issue but I don’t know how to fix this. I have built a dozen drivetriains (well, 11.5) and I have never been able to fix this issue while using all omni-wheels (I am using an H-drive with the motors locked)
Thanks guys! Today I will ensure the drivetrain is square and no weight is moving around. I will also try swapping out two of the Omnis for standard wheels.
you should also check the logic of the code.
The “repeat score” sequence and the “when bumper1 pressed” both may terminate at approximately the same time, you detect the bumper on both and have a 0.5 second delay before calling “stop driving” and looping around to the “drive forward for 600mm” blocks. Remember, event handlers run in their own threads, so both block sequences are operating in parallel.
2 Likes
Today we tried it with another brain and made sure our robot was built evenly, I also fixed the code so there is only one block telling it to shoot the balls then wait. I also added the built in gen 2 gyro back on the code. This completely fixed it driving different distances but brought back an issue was have experienced in the past when using the built in gyro. It will overturn and then sway back and forth for a few seconds trying to correct the turn. In the end it turns a different amount each time. We would rather have 4 omnis than 2 omnis and 2 traction wheels because 4 omnis make it easier to drive and square up with the goal. We might try moving the brain to the back of the robot and see if that helps.
1 Like
It sounds the the swaying issue is a prolem with the PID tuning. It fits the description of a typical, badly tuned PID. The PID will overshoot, then try to correct it, forever. If you have access to the PID values, try tuning them according to this article Tuning a PID. If you dont have access to the values, see if there’s a different function, or try and make a PID using block. I dont know block very well, but you could attempt this logic:
// Vice versa for turning right.
// This makes it turn proportionally to the distance left, so it slows down
// as it gets closer.
// You can tune a 'P' value to make it better behaved.
dampening = 0.2 // The 'P' value
while (currentAngle > desiredAngle)
// This function is supposed to move the robot left a specified amount
drivetrain.move_relative(left, (desiredAngle - currentAngle) * dampening)