Variability

Hi Cari, be sure to pair up your motors by testing them for variability and finding ones that work well together as explianed by TechBrick. http://www.techbrick.com/Lego/TechBrick/TechTips/NXTCalibration/index.htm

Floyd Kelly (nXT-g Programming Author) also recommends using the motor reset block. http://books.google.com/books?id=-xbfc4ghj4YC&pg=PA261&lpg=PA261&dq=nxt+pairing+motor+reset+floyd+kelly&source=bl&ots=T__0u6KD_C&sig=G4qEZM6wheoSo-dgrYnmqBJLnlU&hl=en&ei=dr3ATLnKK4SKlwfn_I3WCg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBAQ6AEwAA#v=onepage&q&f=false

Thanks, --Todd

A couple more ideas for the list (Please share your compilation when you get it finished).

When using wheel rotations to turn the 'bot, the actual amount the robot turns will depend on the distance between its two wheels, which might vary a small amount for a specific 'bot, and might vary even more between duplicate 'bots. Sources of variability would include pieces not being set tightly together (friction fit) and possibly differences in tires? (I believe the functioning width would be from wheel point-of-contact to wheel point-of-contact).

Also, the gear trains in the motors have a small amount of play (or backlash), some teams make a habit of "setting" their 'bots by rolling them slightly backwards to remove this play. It's likely that some motors have more play than others (older motors wearing a bit, etc). This would come into play when motors change direction, including a pivot turn.

Closest I can come to programming sources of variability is that some might be introduced at very low power levels, especially if one motor has more mechanical drag than another.

I just found a very systematic approach to mechanical sources of variability in the article introducing the University of Michigan Benchmark test by Johann Borenstein -- "UMBmark: A Benchmark Test for Measuring Odometry Errors in Mobile Robots." Google the title (it's a PDF). Looks like it might be a great resource for your team as you're coaching them about variability.

One of the ways I have improved the reliability of the mission is to find places where the robot can hit a solid wall. If you have a flat front or back to the robot, it will help correct the angle of the robot so that it is 90 degrees to the wall. You can also have it move each of the wheel motors a bit so that the robot will shimmy up to the wall and get at a 90 degree angle. Also, if the robot has to travel all the way to the other side of the field, using a touch or ultrasonic sensor to sense the wall so the robot will know when it gets to the right place helps. Keep the touch sensor in the middle of the robot so it does not cause the robot to turn a bit when it hits the wall and keep the ultrasonic sensor low enough that it does shoot over the wall and not sense it.

Cari,

I'd say you hit more of the points than I would have thought of. I think you're well on your way. I thought you were going to leave out sensors, but you had that in at the end. Sensors are really important, and this year's challenge screams out for light sensor use.

There are a few things I can think of that you didn't list (though you might use them).

The use of an alignment jig is the first thing that comes to mind. I preach this religiously and my students don't always use it. They insist they can line up by using the words/graphics in base. But when I force them to use an alignment tool, they find they get better consistency.

Tires coming unseated from the rims is another problem that needs to be checked each time they do a mission. I find this is something that happens a lot.

Bent axles is another problem. Using the smallest axle that does the job helps, but after a while the axles get warped/bent. Checking them periodically and changing them if you need to is important.

That's all I can think of off the top of my head.

Ian

On Tue, Oct 19, 2010 at 8:18 AM, Cari  wrote: > I'm looking for ideas to help my FLL team to understand and deal with > error (variability) when programming their robot to do a mission. We > have always struggled with getting our missions to be repeatable. > > I would like a list of conditions that could introduce variability. > Things like...if the board is dusty, and the wheels slip, the robot > won't travel as far as expected. > > And, maybe more importantly, I would like ideas about what can be done > about it? What kinds of methods could be used to eliminate or > compensate for it? > > We've been working on this for a while, but I still sense that we are > missing something as we still struggle with variability and > repeatability. I feel we often chase our tails a bit correcting the > last run, only to have the next run be a little off too and then > correcting for that. I suggest that they do the run several times > and correct the average of the runs and not individual ones. But > even so, we still spend a lot of time trying to get a repeatable > robot. > > When we are trying to hit something small, I often talk about needing > a bigger fly swatter. I use the analogy of trying to kill a fly. We > have a better chance of hitting the fly if we use a bigger fly > swatter. > > We also know about the mechanical solution of using a funnel-like > shape to mate up with a target to assist alignment with the target. > > We have talked about momentum/inertia and how going fast and braking > suddenly can cause you to overshoot your target. It is best to slow > down as you approach the target. > > We have talked about the tradeoff between speed and accuracy - and > finding the optimal speed. If you want accuracy you need to go > slower. > > We've talked about having a rigid robot, and how something flopping > around (loose cargo?) could cause random forces to act on the robot, > and thus introduce variabililty. > > Maybe there is something with our programming methods that we don't > know about? We are using NXTG. > > In programming, I think we've come to appreciate swing turns (one > wheel stopped and the other moving). It seems to be easier to control > since only one motor moves. (This is compared to a point turn where > one wheel moves back and othe other forward. We are using a > differential drive - two wheels each powered by its own motor). > > We use sensors to navigate when possible. So we use sensors combined > with odometry. > > When we watch YouTube movies of the robots that get the perfect > scores repeatably... We realize it can be done, but still at a loss of > how to get repeatable performance. > > Anyone have any suggestions? > > Thanks, > Cari Norton >