Our autonomous strategy - we plan to get to a mobile goal and pick it up. Which sensor is appropriate for this approach? Ultrasonic range finder or light sensor? We are already using shaft encoders to ensure robot travel is able to travel specific distance and in a straight line.
Robot has to wade through yellow cones on both sides. How do I detect that robot is closer to mobile goal and not the yellow cones? Which sensor will be able to distinguish between yellow cones and red or blue mobile goal?
Truthfully, the best approach is just fine-tuning your existing code with shaft encoders. If you can use those correctly (and the robot is placed in a correct starting orientation at the start of the match), there should be no reason why the encoders couldn’t work consistently. If you’re worried about the robot hitting cones and veering off track, use a gyroscope to ensure that the robot maintains the same angle when driving (ensures it goes perfectly straight).
Thanks. But the placement of mobile goal is always unpredictable - it depends on how the volunteer places it on the field before start of the each game - it is not at fixed position. So was trying to find out if any sensor would help in reaching the mobile goal with 99.99% accuracy - even if it is placed couple inches ahead or back on the tile.
If I use PID control logic to maintain the straight line drive of robot - do I really need gyroscope in addition to this?
If your mobile goal lift requires such extreme precision in the placement of the mobile goal relative to the robot, I would instead suggest working on the mechanical aspects of the robot so that you don’t have to be as precise, which would help the robot during driver control as well.
Right now, my autonomous has the robot go an extra 4 inches than where the mobile goal is placed, just to make sure that you’ve gripped it firmly. If it is slightly to the left or right, the mobile goal’s density will actually guide my robot into the right spot, amazingly enough.
As for a gyro, you don’t necessarily need it. If you’re using PID based on your encoder values, then that should be fine enough. I just like the gyroscope for PID turning, so I use it for the driving forward and back functions as well. It’s completely optional.
Ours just goes forward an extra inch or so, worst case scenario it pushes the goal a little before picking it up. If your issue is the goal being too far to a side, code can’t really fix that, do that funnel thing.