Hey,
i have some question about using sensors for an autonomous mode, last year we had a simple autonomous, with jus some values to the PMW’s and it worked about 75%, so it was a good one, cause we were rookies.
Any ways i jus wana clarify on how will u go to programming the sensor autonomous. From what i understand the reflector sensor return a value of 0 or 1 and based on that you can have your robot move. I have one question tho, what if your robot if going straight and the reflector tape jus has an curve as in it turns, and now u get a value of 0 from the sensor, how do u get about to calculating which way to turn.
The other way to program this might be to make it turn a little al the time(as in go left and when the sensor is 0 go right and vice versa) but i dont think this way will be very fast.
Last thing which type of autnomous do you prefer and if u prefer sensors which sensors you prefer.
thanks a lot for ur time.
I will throw a little advice at you… forget the sensors as line trackers and stuff… their are much more effective ways… I would recomend if you are tying to do something similer to 2k3’s game use a gyro. A gyro always works as long as you have failsafes in your programming. Remember the gyro will only work as fast as your controller… make sure that you have failsafes for failsafes. Use an indicator also… its a great failsafe. If you want I can run over the basic principal of a gyro with you on AIM sometime. It is very simple to get on the robot… the hard part is the failsafe programming. If you did a gyro and you tended to get hit from the rear (throw a couple of limit switches on the back of the bot on a bar so that if they are closed your program goes into a lock-motor mode (heats the motors) and continues to count on the gyro with little failure… you can then do a “program jump” to a default program that performs a basic operation. It is very hard to explain with out giving you pictures and some coding to see… I will see if I can dig something up.
It is possible to do it with 2 light sensors. That way if the left is not sensing and the right is, you are off to the left, and vice versa. No matter how you do it though, it’s probably going to be jumpy and slow.
The best way of doing it is using a positioning system such as the one Wildstang used to program their incredible automode. I think they used the gyro to figure out their anguilar position, a pot to figure out the rotation of their wheels in relation to their bot, and some sort of velocity detector on their wheels. You can also use accelerometers or an assortment of other things.
Once you know your position, you can just tell your robot “goto (x,y)” and hope it makes it there. Of course, only a few teams had that kind of capability last year
hey i’ll love all the help i can get, though i dont have AIM, i use MSN messenger…so if you can give ur contact on there to me or add me at [email protected]
Well, I developed an autonomous program that doesnt use any sensors(yet) but rather records driver input and dumps it to EEPROM on the RC. I’m trying to incorporate a sensor based error-checking method, and one that eliminates wheels slippage. I’m getting close, so keep your eyes peeled.Oh, and for those who’ve used it or not, It’s called CopyCat, and there’s already a version for the past year’s control systems up in the white papers.
As far as last year, my team decided to try linetracking. It was quite a waste. Not only was it slow, which defeated the purpose, but it also kept screwing at the ramp. We found dead-wreckoning to work best, sometimes not even using any sensors at all. The best way to utilize sensors in that type of application is for error-checking.
Yeah last year we tried line tracking also and ditched it because it was too slow. Luckily we only needed to follow one path, a tight arc around and up the bridge, so we just used a caster we popped down which lifted our back wheels off the ground. The caster was at an angle so it made the arc.
It was pretty fast, but with no sensor input we had to make sure other variables like boxes and low batteries didn’t affect the arc too much. Errors in the amount of time we did the arc were amplified as we went up the bridge.
Hmm about the gyro thingm i am very fascinated by that can u tell me or show be an basic program which incorporates something like that, or give me a link to start me off. It will be really helpful
Well, I wasn’t going to show you a basic program … but rather the P-basic variety
The team laptop with the code from last year, however, is undergoing repairs. I’ll explain the concept to you though, if that helps. The ‘gyro’ is really a yaw rate sensor, meaning that it tells you your angular speed (omega). To get your angular position (theta), you have to integrate the speed (since, from physics, theta = Int (omega) dt, where omega is a function of time).
So, what you do, is every cycle through the code, add the value of omega to the current value of theta (initialize it to zero). This should approximate your angular position, and you can come up with some empirical numbers to convert the nasty numbers they give you to nice radian or degree measurements if you like. But be careful for a couple of things; namely, you don’t want to turn faster than the gyro can keep up with you, and two, your angle is measured with respect to where you started from (the theta=0 point), so be very sure that you put your robot down in a similar position if your autonomous code depends upon the angle you are to something on the field.
This should, at least, get you started. Obviously, there are some things to fine tune the code, depending on its application, and, possibly, on your robot.
The general idea was to take gyro_sample samples from the gyro, then use the average to see if the robot was heading straight or veering to one side. It would then correct by a constant * the difference between the desired and actual gyro readings (the constant is 1 in this code, that changed in later versions I can’t seem to find anymore).
right_target and left_target are motor speeds, before being sent through a protective filter.
Keep in mind that this DIDNT WORK. I’m not sure why- I blamed it on the slow refresh of the RC, but it’s much more likley due to my terrible programming
We ended up dropping the gyro entirely because it added complexity to a system that was working fine without it. I think that with some planning and the new RC strong programming teams could have a lot of fun with the gyro.
Last year, trying to get the gyro to work was horrible. I mean, it sorta did what it was supposed to, but there was too much “jitter” in it. If you used the dashboard viewer to look at the gyro output… it was going all over the place, especially when you got hit, hit things, or was going over that wire mesh (especially that).
I know some teams got it to work by using some special stuff to reduce the noise in the output… but I never quite figured that one out. And the usefulness didn’t outweigh the difficulties of getting it to work so I never bothered either…
Last year my team sucessfully used the Gyro, but we used an off-board processor (an Atmel AVR). when needing to track a line (going straight) we would read the theta, then, each loop, compare the current theta with the first one and multiplied the difference by some fudge factor and then added/subtracted from the left/right wheel velocity setpoint and make the robot curve back onto the line.
When needing to follow a curved path (e.g. 180) we would just set differential wheel velocity (we used encoders on the motor shaft & controlled velocity rather than power) for a given curve and then loop waiting for the theta to change by 180.
Worked like a charm: straight out from the start, tight 180 to the center of the ramp, straight up and over. Worked every time, even when boxes were stacked in front of the robot. We had four modes: up the ramp left/right, back up as fast as possible (bash the opposition) and do nothing.
The code, attached, is a little state machine task: for the first 5 seconds (5 * SYSCLOCK) it does nothing, letting the robot “settle down”, then it reads the gyro value and assumes this is the zero point. Then it settles into the -1 case where it just integrates the gyro output and makes various value available to other programs.
What I don’t show is that we filtered the gyro on the electronics board (33k resistor feeding a .1uf capacitor) to get the gyro output bandwidth below 100hz.
