To all teams using the IR beacon to knock over the 2x multiplier, I am interested in what algorithms you used to get there, and how they worked. During the build season I myself experimented with several, using the EduBot, of a wide range of complexity … and as I was about to decide on a very complex, trig-enabled algorithm, one of my mentors suggested I use a simpler approach. It turned out to be quite elegant, really.
I mentioned it before on CD (and was told it would never work!), but here is the basic premise of it: We have three IR sensors housed in a metal casing lined with black corrugated cardboard to reduce internal reflections, and have a small, adjustable vertical slit in each. The sensors are aligned so that one is put facing the right, one the left and the other forward (each housing box can be turned a given angle to adjust just when the sensor “sees” the beacon … this can be used to hit the other team’s ball, just ours or both).
As we put the robot down, we hit a switch to tell it which beacon type to look for. Then, when auto mode starts, the robot drives forward until either the left or right sensor “sees” the beacon, whereat the robot stops, then turns either left or right accordingly until the center sensor “sees” the beacon, at which point we know we are facing the beacon. Here the robot moves its “tusks” and its “arm” to a position so that we can knock down the ball, and then it drives forward for a short burst of time. It is worth noting that this arrangement lined us up with the beacon every time, and the only issue was with coordinating the “tusks” and “arm” correctly … which by the end of the competition, I had worked out rather nicely.
It is a simple, uncomplex algorithm. We disgard the servo setup entirely, and just use three sensors. However, its simplicity makes it work fast and reduces the liklihood of either mechanical or programming failures. I’m interested in finding out how others modified the setup we were given, and to what success.
That is a great way to do it! At one point my team had 4 servo sensors on the bot, but eventualy we went down to the old 2. We didnt do any real changes in what first did other than almost compleatly rewriting the code, making minor changes in the way the sensors are positioned on the head. We do have a very overly complicated navigation system that is completly untested on the frc! How have they been working at the comps? We cant wait to test ours at buckeye!
We tried to use the ir at anapolis and found that there is way too much interference. Most of the time our sensors could not lock on. Thank god we had a programmed overide and a accurate dead reconing code.
we do exactly the same thing, except we us a yaw rate sensor integrated to give relative heading to measure the turn right or left
it works extreemly well
also - we dont use interrupts for the IR sensors - if you connect them to rc_dig_in01 and 02 there are interrupt flags that get set if the sensor toggles the input pin - all you have to do is poll the flag, see if its set, and if it is then you know the sensor saw the beacon (and you clear the flag in SW)
we did notice the sensors pick up stray triggers once in a while, so we wait until we see it in the SW loop 3 times in a row (about a 1/8th of a second)
I was somewhat suprised, actually – there aren’t a lot of robots that can consistently knock down the 10 pt. ball. Even fewer that attempt to do it using the IR sensors. Unfortunately, I can’t say how the finals at VCU went … (I was … err, elsewhere), but at Annapolis, I don’t think the majority of bots in the finals were knocking the ball over (granted some robots did have the strategy of positioning the mobile goal under the release and specifically did not want to knock it over).
Really? We had absolutely no problems with our IR sensors … except for that a tiny opening in the back of one produced some interesting reflection errors, which was duly noticed and fixed with some handy aluminum foil. Other than that, we didn’t get any stray signals or anything of that sort, and found that we could control our acceptance angle very accurately. What type of set up did you use? The heat shrink?
Our bonus ball mode is completely untested. We initially were going to do line following, but lost them due to space and and weight. Our current setup is driving straight and turning. We probably will never do that, as we have a hopper on our 'bot and want to be there to catch 'em all. (And, yes, we can catch all of them.)
Why not just use dead reckoning? In general we have observed that the more complicated an auto mode gets, the less accurate it gets, and that extends just as much to sensor using robots. With some thought you can set up a really easy to maintain and tinkerable state machine to adjust motor values, and from there its just some testing to get it to work right…
A lot of people stopped by our pit in Sacramento and commented about how simple our idea for knocking the ball off is (a fiberglass whip on a spring, lowered by a pneumatic cylinder), and it kinda surprised me. Simple mechanism means a simple program, and that’s why we were so successful in hitting off the ball (until day 2 when one of the motor transmissions got changed…that’s the downside of sensorless automodes =\ ).
I don’t think anyone at the st. louis regional used ir for competition (correct me, team members, if I’m wrong). Most of the successful autonomous modes were dead reckoning, although a few line followers got close (hit the frame around the bonus balls or some other such small failure).
the problem with dead recogning is that as your bot gets wear and tear during the matches, and your batteries are at different levels of charge, the speed and direciton your bot will run will change enough to make you miss the ball
the IR sensor scheme the originator of this thread created solves part of that problem - no matter how much the forward speed of your bot changes, it will know when its reached the beacon off 90° to port or starboard - its will know where it is on the field at that instant
our bot is very similar - and since we get to the ball in about 5 seconds, it would be a waste of time to just sit there for almost 10% of the match
so we back up and turn towards the drivers, turn our front roller on and drive through the field of freshly fallen balls to try and capture some of them.
dead recogning is ok if you only want to go straight for several seconds and do nothing else - but I have to disagree with one of the previous posts - if you implement your sensors correctly then your bot will get the ball more reliably, not less
and it will be able to do other things - and compensate for stuff like, oh I dont know, the opponent teams bot getting in your way and you have to push it backwards on the way to the release ball? :^)
We use a fresh battery in every single match, no exceptions, and test on fresh batteries at the lab, so thats not a problem.
Second, the only serious wear problem we’ve had has been tread (we use waffle tread, it goes quickly), but surprisingly, it made no difference. The program we took from our lab, with our creaky, worn practice bot with almost no tread left worked perfectly on our smooth practice bot with new tread.
I maintain that sensors will only complicate the process, though if you do not have a practice robot and no way to test and calibrate dead reckoning, it can be difficult. A sensor program could conceivably be written and used with no testing…
where do you get a fresh battery from in every match of the elimination rounds? they take about an hour to recharge after a tough match and they only gave us two batterys?!
your right about having to tweak the DR auton modes - we did not get any real testing time on our bot for auton before we shipped it - but by the end of the day friday we were hitting the release ball dead center every time - and all we use to naviagate is the fixed IR sensors and one yaw rate sensor (i mentioned this above)
it seems odd that you would be against using sensors. Put a pair of winter gloves on, put on a blindfold, and try to make a peanut butter sandwhich in your kitchen with YOUR feedback all turned off.
Sensors provide feedback - feedback is information - more information is always better than none :^)
I agree. If you do your sensors (and code) right, You don’t need to calibrate between every match. We have a routine that we run ONCE, during the 7 AM practice round, and base everything on that.
And I’m not worried about other 'bots. If we go against a wall, the wall looses. If we a go against a bot, who do you think looses?
We have all kinds of batteries from previous years. We bring a cart with about 8 batteries and at least one (maybe two, not sure) charger(s). The biggest challenge is keeping them organized into which are charged and which aren’t.
Although I do agree that dead reckoning has serious drawbacks. Feedback is important.
Something of a hybrid could work. Our team had light sensors mounted facing our wheels. Weglued circles to our wheels that each had about 100 black and white stripes. The light sensors gave us feedback on the transitions between white and black as the wheels spun and gave us accruate wheel counts that we used to drive straight. (Our drive train was…not cooperating and veered to the left in autonomous when told to go straight).
Although we didn’t use it to attempt to hit the 10 point ball, you could use these wheel counters to tell you exactly how many revolutions you’ve made at any point in time, and if you know the circumference of your wheels and the distances on the field, you could do some pseudo-dead reckoning with feedback. =)
I think that would be the best solution for a lot of teams who, like ours, may have had trouble with designing a system for using the IR beacons. The wheel counters were easy(ier?) to work with and could give you feedback.
Because a robot without feedback is a robot out of control. =)
(Our team didn’t have any actual physical mechanism on the robot that would have been able to knock off the 10 point ball, in case you were wondering why we never tried. That and I just thought of this idea while writing this post. )
We had about 8 batteries at competition this weekend, and kept cycling them through our three chargers…during elimination matches we ran close to out, but thankfully we didn’t have to play any tiebreak matches and stayed powered through it all. If all else fails, I am almost positive another FIRST team would offer a spare battery (especially if they are not in elimination matches) if you are out of fresh ones. Even then, we had about 40 minutes between matches, so if you have 3 batteries you could have stayed powered through preliminaries…sorry if I am discounting teams that don’t have the battery supply we do.
Perhaps my aversion to using sensors comes from the ease of using the whip to tap the balls off the tees. We don’t have to turn and face into the ball; rather we run along the wall and in fact use the wall somewhat to correct our angle and hold straight. We are planning on putting a light sensor to detect the line and tell us where to stop to only hit one ball, but any more sensors would have only put more hardship on us programmers (we had enough to think about on the arms).
Another problem is serious sensor malfunction. Team 60, the team we collaborated with this year, lost in semifinals because their proximity sensor that was counting gear teeth was malfunctioning. Their autonomous mode, based on this sensor, then flung them into a wall, and they lost a pneumatic fitting, and all pressure. Eventually they lost the match and couldn’t get repaired in time for the next one. With our dead reckoning, we can tap the wall a little hard, but we feel safer than if we were letting the robot decide things more.
The problem with dead reconking is that you are blind. Sensors give you some sort of input into the outside world. So, if someone rams into you, code based on the IR sensors will still function properly (provided the bot can shove pretty well!) … or if the robot is placed down in a position where it veers off to one side, the IR code will not be effected … and other examples abound.
SO far as the batteries, I believe you can only use the 2 they provide in the kit. I’m sure someone will get around to posting the specific rule, but I’ve got to be off …
I personally believe that sensors would be more useful if your target was moving or at an unknown location. As it stands, teams have the exact position of stationary objects. I’m guessing most people use sensors for two reasons:
To generate outputs that would have been too complicated or innacurate to write manually.
To have your robot adjust dynamically to changing situations.
As for number 1, the outputs generated aren’t usually too complicated (ie the robot just has to move in a straight line). With a little testing, it’s possible to determine these values. I personally prefer to have values I know work hard-coded into our program, as opposed to rolling the dice with sensors.
I believe number 2 is less of an issue than people think. I’m not sure that:
a) More than a few robots will be able to reach the center with enough force and time to disrupt you.
b) Sensors will help if you are moved. Most of the dead reckoning programs aren’t terribly complicated. They don’t tend to involve intricate movements that can be disrupted easily. If something can move your robot enough to seriously hamper the dead reckoning program, I’m not sure sensors would help.
I also like dead reckoning this year…swamp thing had two very impressive autonomous modes (and possibly a third i wasn’t sure) which i believe were dead reckoning…one went plucked the 2X ball off the mobile goal, and the other was to drive at an angle and move their closed claw to the height of the 10 pt ball then simply opened their claw and backed up knocking the 10 pt ball right off…so simple and very impressive if you ask me…
In SPBLI only two robots could knock down the 10pt ball, and they did it only a few times. Winning automodes just drove forward and stopped to either get the mobile goal or get up the ramp. One of the winning teams could get up to the bar in less the 45 seconds total because of their simple autonomous mode.
We probably will never do that, as we have a hopper on our 'bot and want to be there to catch 'em all. 
)
