I was wondering if it would be wise to use an ultrasonic sensor in the 2015 game to stack the crates once the robot is out of the gold boxes. If there is a better solution than using an ultrasonic please let me know and explain your solution. I’m open to any ideas. Thanks
Would you mind sharing what use the ultrasonic sensor would have? It’ll help us give you other solutions/ideas.
The only sensors in this game that were good to have were the gyros and encoders, the other sensors that might have been helpful depending on your robot setup are potentiometers and well some form of limit switch.
I think that if you are trying to do distance calculations, the PulsedLight LIDAR-Lite module would be best. In our experiences it has been more accurate than an ultrasonic sensor, since it uses infrared lasers for distance measurement which are less susceptible to noise/environment variables than ultrasonic sensors.
http://www.robotshop.com/en/lidar-lite-laser-rangefinder-pulsedlight.html
Here is our LIDAR code in java. We connected the sensor to the I2C port on the MXP since at the time, the RoboRio I2C port was broken. We borrowed the base of the code from here and modified it a little.
HTH.
We had an ultrasonic, as I recall. As well as multiple limit switches.
The ultrasonic sensor was mounted inside (quite literally–mounted inside the tube, pointing to the inside of the robot) of one of our intake arms, and on detecting a tote would tell the arms to close and start the intake wheels spinning to bring the tote in. At that point, the limit switches and encoders took over to stack the tote when it was in position.
Affordable ultrasonic sensors that I found had too large a (what we call in underwater active sonar) “direct blast range”. That is, you cannot get any data inside of ct/2, where c is the speed of sound, t is the duration of the pulse, because you are sending out signal at that point. Even low end bistatic sensors (separate transmitters and receivers) had too long a minimum sensor range. We had rather better experience this year with Sharp optical range finders and (when you want **really **short but nonzero ranges), capacitive proximity detectors. Especially if you have an active intake, nothing beats a good old physical contact limit switch that protrudes just beyond a physical stop, or is located out-of-line with the game piece.
624 used an ultrasonic sensor with great results this year (super cheap HC-SR04s from Amazon). The hard plastic of the totes and cans seemed to work very well with the sensor, and distances were accurate to a tolerance of about ± 0.5 inches.
We used the range information so that the robot wouldn’t try to pick up an object unless the sensor read a distance less than a minimum threshold. Because of our lifter geometry, a tote needed to be much closer to the back of the bot than a can to be picked up, and having a distance measurement made it easy to have different thresholds for the 2 objects.
We tried an ultrasonic sensor last year, but the fabric covering of the ball seemed to confuse the sensor (absorbing echoes or something), and it was difficult to get a reliable measurement. It definitely seems to depend on the game piece, but if it’s any sort of hard surface, ultrasonic sensors are worth considering.
i forgot to mention that…but overall I think first did not design the game with programmers in their mind.
I have to disagree… teams could go for more complex drive trains, like butterfly or swerve. Autonomous was also a pretty good challenge when you go for the tote stack, and I saw a few robots with automated stackers at the, yes, chute door.
This was our most complex and complete programming project ever
hehe chute door
My thoughts on Autonomous: The vision tape was close to useless, first gave us no way to image process from the start unlike last year. All of the objects and points are static, they do not change from game to game unlike how last years there was 2 different possibilities that gave a 15 point bonus. Last year was a much more well thought out game, then this years 3d tetris.
As for the chute door: Robots that utilized the chute door for a automated stacking feature like team 148 were ahead from the start.
as for programming all of it: Auto only relied on a max of 2 encoders and a gyro and the pickup sensors. There was no hard algorithm, aka move forward, turn, turn back, pickup…super simple, and if you had enough time you could actually program this all with timing.I myself actually had a 2 tote auto with time.
final thoughts: I guess i was a little wrong, I would just like to see a more rewarding uses for vision, and some sort of target or movable object and an endgame. Or maybe first gives people incentives to use other programming languages like java or c++ such as working vision libraries for them wrapped around opencv or something fancy