approach to autonomy

[Mike375]

I'm fairly familiar with C++ and the basics of programming the robot's basic functions: mapping joystick commands to relays/speed controllers, and how sensors work, but this autonomy thing is a little above my knowledge. The approach I would like to use is to have the robot roughly follow the path of the white line, but just by programming how long each motor should be powered for, rather than losing sleep over the optical sensors. The way I am hypothesizing doing this, since I'm sure I wont be able to test it for a few weeks is as follows:

The first thing I would like to do would be move forward:

1) declare a variable, I'll call it motor_on_fwd (do i need to identify it in the initialization constants section too?)
2) Create an autonomy section in the Perform Operations section (along the lines of the one presented on page 18 of IF's Programming Reference Guide)
3) This is where I get a little confused, if i was doing this in C++, I'd write it as an accumulating loop

while motor_on =! # (# equaling the amount of time i want to move divided by 26 ms)<--which i read is the amt of time for 1 cycle
{
p1_y=255
p2_y=255
motor_on + 1
}


I'm not sure how exactly the while loop works in pbasic or what it is called, so I'm going to need some help there.

If I'm just completely barking up the wrong tree here, please let me know.

Also, is there any way I could try this method out on our robot from last year in the meantime, or did that control system not have this function ?

Thanks in advance for any advice,

Mike

[Skabana159]

What I have done in the past is quite different than your approach. Two years ago, while writing an auto-balancing routine, and last year for our gear-switching routine, I used an entirely seperate serin/serout loop. This is a sketch of what it might look like, if you were to set the motors to go forward for, say, 40 loops of time. Let us then assume that after 40 loops, it goes back to human control and your regular default program loop, called mainloop.

loopcnt var byte 'a byte to count loops by
loopcnt = 0
autoloop: 'our loop for autonomy
serin 'this takes data from sensors, get the right syntax from
the default program.
PWM1 = 254
PWM2 = 254
loopcnt = loopcnt + 1
if loopcnt = 40 then mainloop
serout 'this sends data to relays and speed controllers. get
syntax from default program
goto autoloop

I would not bother with the middle man of your joystick variables, p2_x and p2_y. Simply go straigt to your motor output variables, PWM#, or whatever meaningful alias you would give to them. The default program does warn against having more than one serin statement. It is okay as long as they are in seperate loops.

[Caleb Fulton]

So serin/serout loops can be NESTED inside the main loop?

[Ryan Meador]

For someone who's claiming to not know what they're doing, you're asking all the right questions and definately on the right track. Here's the PBASIC translation of what you're trying to do (although it's the old PBASIC, not this mystery new version that would make life so much easier):

' start with init code and serin statement. this goes in the main loop

' delcare variable; since this isn't tranferred from
' anywhere, you don't need to define a constant
motor_fwd var word
desired_on_time con 200 ' whatever you want...

if motor_fwd > desired_on_time then no_motor
PWM1 = 255
PWM2 = 255 ' this may need to be zero if your motors have reversed polarity

motor_fwd = motor_fwd + 1

no_motor:
' continue with other code here and serout

Ok, enough program. Now for the explanation. You can't have your own loop, because then you wouldn't be sending data out to change the motor outputs. You have to make your code able to be called repeatedly, rather than once. I hope I'm not being too condescending, but this is a good metaphor: imagine you have a function that is called once a frame for every frame in a movie. The function can't just sit there and run, it has to move the actors around on the screen just a little bit and then wait for the next frame.

And yes, you definately can simulate this on last year's controller. Last year's hardware doesn't have support for autonomous mode, but you can accomplish the same thing by just ignoring all user input in the program. My team has done experiments on past years' robots to make them perform a variety of motions. A word of warning: when you first begin testing your code, don't set the outputs to maximum... an out of control robot with the pedal to the metal is dangerous This warning courtesy of my formerly-bruised leg.

EDIT: Serves me right for taking such a long time to write a reply... there weren't any when I started writing Anyways, nested loops don't matter. The only thing the robot controller ever knows about what goes on inside your program is the input and output. As long as it arrives on schedule, it's happy.

[rbayer]

First of all, I think using the optical sensors would actually be easier than trying to do what Woody called "Dead Reckoning". If you want some sample optical sensor code, we used them last year to track the goals. That code is available at my website and is called CogCode. http://www.robbayer.com/software.html

[Jnadke]

Using the optical sensors is rather easy to follow the line on the ground. All you need is 2 optical sensors. 3 would be more fail-safe and would allow you to travel at a faster speed.


Basically, just mount the optical sensors fairly close to eachother so that they can hit the tape when the tape is between them. Testing will be needed to be done to determine the best "gap" between the sensors. Mount them facing the ground so that one is on the right side of the line, and one is on the left.


Then, basically program your robot to move at reduced speed. Program it to do this:

if right_sensor_senses AND left_sensor_doesn't_sense:
turn_left

if right_sensor_doesn't_sense AND left_sensor_senses:
turn_right

else (otherwise)
move_both_wheels_same_speed


Basically, the robot will turn, while still going straight, and follow the line if one sensor can't see anything, until both do. Do do the last part as an "if" statement.


This is the most basic way of programming the robot to follow the line. It allows the robot to still move while seeking out the line.

[nwagers]

I agree... use the optical sensors. If you've ever used the lego robots you know that using time as a guide it is very inconsistent. Something as simple as battery voltage can throw you off by a few feet. You can easily practice by attaching 2 optical sensors to a board and have 2 LEDS representing left and right turns. If you do decide to use the time as a guide may I suggest using delta_t (missed packets since last "serin" line) as well

mainloop:
serin
time = time + 1 + delta_t

select case time

0 to x
run motor
x to y
next step
and so on...

endselect

serout
goto mainloop

there are supposedly some new programming commands this year, it should simplify the code. Remember to declare time big enough to handle the amount of time you need (a byte is about 6 secs, a word is about 27mins)

[Jnadke]

Never, ever set your motor's to 255. Always 254 or lower.


This is because two 255's in a row in the serout is a reset command for the main robot controller.

[rbayer]

One thing to be careful of: your robot starts executing code the moment the power is turned on. This means that your time will have grown to be very large by the time the match acually starts. To avoid this, test for when your robot is no longer disabled. It's one of the bits in the comp_mode byte.

[Mike375]

another question, since I am unfamiliar with the optical system. I dont remember the lines being made of retro-reflective tape, will the sensors be able to detect the lines just on the contrast with the carpet?

[Jnadke]

Originally posted by Mike375
another question, since I am unfamiliar with the optical system. I dont remember the lines being made of retro-reflective tape, will the sensors be able to detect the lines just on the contrast with the carpet?

The optical sensors use infrared light to detect where a reflective object is.

Carpet will/should absorb infrared light. The reflective tape, however, will reflect the infrared light back to the optical sensor.

Be careful, where you mount them, because metal is reflective too. The optical sensors might get confused. Also, note that there is a screw on the optical sensor labeled "gain". This tells whether the beam is "wider" (more spread out) or "narrower" (straight ahead). You might want to play with this to determine the optimum configuration.

[Ryan Meador]

Originally posted by Jnadke
Never, ever set your motor's to 255. Always 254 or lower.


This is because two 255's in a row in the serout is a reset command for the main robot controller.

I've never heard of this before, and in past years I've never had a problem with it. Could you direct me to the documentation that says this? Thanks.

[nwagers]

This is the link you may be looking for:


http://www.innovationfirst.com/FIRST...ence_Guide.pdf

However, this only says that you should not use 255 as a PWM output. Jnadke is correct two bytes of 255 will signal a new packet to the output processor in the RC. This is also why both relay outputs are spaced out by the PWM outputs (relays can be 255). Your code has worked with a 255 pwm output because there were never two in order.

[Mike Soukup]

rbayer & nwagers are correct, try to avoid dead reconing whenever possible. Many FLL students figured this our the hard way because robots behave differently as the batteries drain. Motors slow down and you don't go as far in a given time interval as you'd like. So instead use the line, sense boxes using the retro-reflective tape, or use some other sensors. But try to avoid time based (or program loop counting) whenever possible.

[edit]
I forgot to mention another reason that dead reconing is bad. If a bin or robot is in the way, you won't go as fast as you will w/o objects in the way & therefore not as far in the time interval.
[/edit]

Mike

[rbayer]

Originally posted by Mike Soukup
rbayer & nwagers are correct, try to avoid dead reconing whenever possible. Many FLL students figured this our the hard way because robots behave differently as the batteries drain. Motors slow down and you don't go as far in a given time interval as you'd like. So instead use the line, sense boxes using the retro-reflective tape, or use some other sensors. But try to avoid time based (or program loop counting) whenever possible.

Mike

Given our $200 of electronics, I suppose it would be possible to add an rpm counter to your wheels. This would make it possible to be sure of exactly how far you had gone/what speed you were going. It will be a pain to setup in PBASIC unless you can find a sensor that keeps track of total rotations and sends that as its "data".