Ultrasonic sensor for 2015 game

[GeeTwo]

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.

[randantor]

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.

[Fauge7]

i forgot to mention that...but overall I think first did not design the game with programmers in their mind.

[MaGiC_PiKaChU]

Originally Posted by Fauge7

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

[Fauge7]

Originally Posted by MaGiC_PiKaChU

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