Anyone using sensors???
 

I was just wondering if any teams were opting for linetrack over dead reck or were adding that in as a demo ability for sponsors or anything.

Does any team plan on using a tote seeking ability, or have a working tote seeking program?

I believe the line seeker bots will fail. It would caus a hassle to do, but our team may, or maynot be using them...honestly I'm not sure.

Dead reckoning seems to be faster, easier, and more reliable. I haven't yet seen a benefit of sensors, unless you count the cool factor. We probably will hook them up after the competition for demos and such.

I have no idea what all the strategies mean (like, what does dead reckoning mean your robot will do). But yea, sensors will scale high for the "Oh! Sweet mama! This bot follows this line...mommy, can I buy this toy?"

looking at all the variables in dead reckoning, we opted to make a line tracker, we use 6 sensors to do it, (3 per side) and we got it working almost 100% reliable and its quick, still in the tweaking but it works nice. with dr there are too many things that can go wrong, one wheel slips for a second and its off. just a little risky for us

Nice i get to see your 6 sensor linetrack at LI regional right?

Actually we are working on a intergration of both dead reck and line track into one code. Just wait.... it's gonna be good.

we have the capability to do both. six sensors? that would be nice.

we use 2 sensors to do line tracking. they are situated side by side towards the front of the bot. not saying anything else as far as exact location of the sensors !:cool:

anyone who wants at the events were at can come take a look at our sensors array. we have it set up differently for each side of the feild. we were having a little problem getting it to track the line like a conventional tracker, so we set up the sensors in a v formation, and enabled one side at a time depending on where we start on the field. from there it will go and only use one side driving it up to the ramp. then the gyro detects when we reach the ramp, wings come out, and we go full up the ramp slighty drifting into the middle by the time we get up to the top and take down a cool 5 stacks. our auto code programmer joe will be around if you have questions about the auto mode

I would think that a sensor on front, and 1 on back would be a better usage for them. The back detects a change of the line, and turns the right way if it is detected. Same with the front (this is if your front and back wheels drive independently)

Dead reckoning is where the program tells the bot to go forward for X number of program cycles, then turn, then go forward again, then turn, then accelerate up the ramp and into the boxes :D

You have to use trial and error to make sure you go the right distance and your turns are right.

The big problem is wheel slip. We have a dead reckoning program loaded, but we have it so it works on linoleum because we didn't have enough carpet to test it. So the first practice match we are going to take off all the breakables, put on all the armor, and use that to tweak the program for carpet.

Another problem is colliding with another bot, but we figured that by the time you hit another bot you would be on the ramp and the line tracking wouldn't help you any.

Actually we have sensors wired and mounted and a working line tracking program, but with our bot and strategy it is much faster and more reliable with dead reckoning.

I see few advantages with sensors and line tracking, but its a decision each team has to make based on their individual bot and strategy.

we have a 2 wheeled bot. 2 wheels in the back and skids in the front. we took that idea of 2 sensors, and just added a middle one. the rear sensor is right under the axel, mid sensor is about 3 inches out from that, and the front is more onto the corner making a v shape along the bottom of the bot.

dead reckoning - too inconsistent put a few bins in the way and while your robot thinks it is going straight up the ramp it is now going off at an angle. You get a battery that has a higher or lower charge the motors will act differently. just too inconsistent

:ahh:I don't know what you're talking about, but that would be a useless deadreckoning mode. the robot can travel in a curve much easier than in a rectangle. set one POT before the match and have it relate that number to a constant on one of the wheels. the code may look something like: (this is psuedo-code)

if (POT > 127)
right motor = POT + 127
left motor = 127
else
left motor = 393 - POT
right motor = 127
end if

or something like that. Just throw in the gyro, and test if it's going up and step on it.

If you're going towards the ramp with a bot that is knocked off greatly by bins, then perhaps the bot isn't quite strong enough to attack the wall.

Then again, I could be completely wrong and victim of putting too much faith into dead reckoning. Time shall tell...

Out of curiosity, how long does it take on average for you line trackers to get to the top of the ramp? And are you having and problems once on the grill?

its faster to cut off the curve into 90 degree sections than to make a wide arc around to the ramp. If you use dead reckoning to make the same curve that you would if you followed the tape, what's the point?

I agree that your code is simpler, but not faster, at least not for our bot.

We also were planning on putting the gyro in so it accelerates when it hits the ramp, but never got around to it. Yet another thing to be done at regionals.

Yep. This is why we opted for a robot that follows the line. We're using 5 sensors this year ... they're all lined up on the front of TOBOR VI. It's pretty nifty! :) I believe we have a dead reckoning program written just in case we need to use it, but I'm not sure.

- Katie

Alex you are tired or really not with it. Where did you get 393? Actually I am not doing it like that at all. This is how I am doing it.

I think this is right but it is late and I can't find the source I wrote earilier.

maybe this will help explain what I'm trying to say. The distance from point A to point B is shorter in 1 than in 2

Edit- trying to get the lines right
Edit-close enough

First of all, we are not travelling in a straight line, we must travel forward, turn 90 degrees right, go forward, then travel 90 degrees right again.

Second, the distance may or may not be greater, that's not the point. When you don't do an arc, you have to stop, turn, then move, and then you have to accelerate back up to your top speed. When you do an arc, you apply power to the motors continously, and thus you aren't jerky and you save some speed.

Now, it may be different depending on drive train issues, and robots, but it's not as simple as "the shortest distance between two points is a straight line" (unless you are 179 and you can just climb over the rail, thus going in a straight line! :))

Stephen

I'm not advocating an 0 radius turn. There is some arc to the turns, but they would still be considered a sharp 90. Hitting the front lip of the ramp at top speed in our current configuration would be catistrophic, so I say once again: It is a decision that needs to be made in each team, and is dependant on your individual robot and strategy.

I still maintain that cutting of the curve in dead reckoning is faster for most bots that I have seen, but only time will tell.

We have both a curve and a 90-90 dead reck going. I believe the 90-90 program is faster, but sometimes there's a good reason behind using an arc. but i've said too much.

Remember ours didn't work earlier, this fixes it, and 127+256=393 (i forgot that 254 thing) this inverses it correctly, the one we had was backwards (close to 127 was sharper turn than 254). :p

the big advantage to an arc is that is would be variable, and not limited by the line. (you could make it variable with the 90-90 thing, but this uses less variables)

the fastest way isnt a 90/90 turn. The fastest is to back up at an angle and then go straight up the ramp with a very minor correction. We have multiple modes of autonomy, using Gyros, Line followers, and dead reckoning. We are using 5 sensors in a line to detect the line.

This is our config:

| | | | |

this works rather nicely
[edit] ummm it didnt like the way i spaced my little lines, lemme figure out a way to fix em.

Basically, there are two sensors on the far ends and then a group of 3 in the middle.


Cory

We are. I wish we had five sensors to play with, though. We're only using three. We also have some d. r. programs.

Sensors are cool!

Look for our bot doing some cool antics at the Seattle regional!

Oh yeah, we have a pretty cool odometer too. Ill post some pictures in a few days when i upload a whole bunch of our bot.

Cory

We were going to do line-following until our programmer found a better way to use the sensors to count wheel revolutions. Look for some very cool autonomous action from 360 at the Seattle Regional.

we aren't line following...
but then again we aren't exactly dead reckoning either....

sensors galore on our robot... 16 digital inputs and 3 analog! (gee that was fun to wire:] )

Is anyone else out there using encoders? I heard one person talk about odometry.

We got some gray scale mechanical encoders (Grayhill) and are using them on our back wheels.

We do the back up then forward at an angle strategy.

127 + 254 = 127

and it is only 254.

yes encoders.... lets just say that there is a section of our code dedicated to conversion of grey code...and that there are some funny looking things attached to our front wheels:)

I don;t know that much about the banner sensors that we use since I'm not that electrically inclined so to speak, but I hope they are different than the sensors that the LEGO Leaugers use.. While I was volunteering these past 2 years at LEGO League events, I noticed how jumpy those sensors that they use to "line track" are. Do ours have the same jumpiness to them??? I hope not.

I worked a lot with the sensors over this summer for a NASA internship, and while they were somewhat "jumpy" when they were on the verge of sensing something, they tended to be very reliable. Also, I think the jumpiness that I expririenced was probably germain to my project (tracking a contiously moving object through 3-dimensional space), and that the sensors would be very well suited for line tracking. I haven't actally made a line tracker though, so I can't tell you for sure.

Stephen

We were able to hook up some sensors to last years robot and found that there was little to no jumpiness in them.

However the bot was somewhat slow at 3-5 fps, and getting that to work right was hard. I can imagine any team that is looking for 10+ fps to line track is going insane getting that to work.

The problem i found with the sensors is that they really don't pick up the reflective tape at a distance large enough to be worth using. aka tote seeking. though the cool factor is through the roof on something like that it's difficult to imagine it being reliable. The sensors are fairly reliable at a short distance like that used for line tracking. So it is possible that some teams may have perfected such a code.

Elgin:

The Banners are _much_ better than the LEGO light sensors (I hope, anyway). In any event, the location of them on our arm should be able to allow us to use the same two sensors for both line tracking and stack destruction during autonomous mode. Of course, the line follow code is not made yet, but that's another story all together.

I know we attempted to use the sensors; however, some of the were broken in the process *cough*bypeoplerunningtheprototypeintomycar*cough* or when they were working, our speed was too fast in order to stay focused on the line.

Dead Recking was the way to go for us at least.

I did this to a guy's classic car when I was driving a 4 wheeler once, got in a bit of trouble to (-.-);

Sensors come in handy sometimes.

I have faith in you electrical people, Steve! lol

For everyone else, "See" my post in THIS thread to "see" how we wowwed everyone last year with the sensors with our "I.D.A.N. System"

we found the sensors to be too unreliable so we are using a distance measuring and a gyro in autonomus mode. about tote seeking we found to hard to program due to the lack of a constant background (example: the crowd not reliable)

i dont think that 'background' will be an issue...
unless someone out in the crowd is standing at the exact hight of the tape on the boxes and has something retroreflective.

The range of these sensors when trying to sense something not retro reflective is very limited. They cant even sense a hand 1' away.

Odd... the talk of sensors here is only related to the use of them for travelling up the ramp...

However, what if your alliance partner is faster than you by a significant amount? Couldn't you contribute more by using sensors to find a human player stack (so you can steal it immediately when the human control starts) or go and knock them down.

Anyway, that's just another use for sensors if you don't want four robots running into each other :)

i totaly agree...

when i say we have sensors we have a whole range of stuff. From rotary encoders to limit switches to banner sensors to pots to the yaw rate sensor. We did research into some others like other ways of sensing a change in angle and different types of sensors to sense position on the field but we ran out of digital inputs cuz we are using 4 bit rotary encoders (these were fun to wire and figure out the non documented pinout!).

Sensors rock, our team went crazy with them this year!