Ive been chewing on my yellow food wristband every night since the team party on friday at UTC. Every day it tastes better and better...almost as good as the food. Anyone else think so? - Sscamatt [more]
 Chief Delphi approach to autonomy
 Team 51 CD-Events CD-Media CD-Swap CD-Spy FRC-Spy Unsung FIRST Heroes WFA
The Chief Delphi Forums are sponsored by Innovation First International, Inc.

#1
01-05-2003, 06:13 PM
 Mike375 Registered User #0375 (Robotic Plague) Join Date: Sep 2001 Location: New York City Posts: 46
approach to autonomy

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 ?

Mike
#2
01-05-2003, 06:32 PM
 Skabana159 Robotics and Field Hockey AKA: Jesse C. Owens #0159 (Alpine Robotics) Team Role: Mentor Join Date: Mar 2002 Rookie Year: 2000 Location: Ft. Collins, CO Posts: 92
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.
__________________
"What most people do not understand is that the Buddha, the Godhead, resides just as comfortably in gears and circuits as in hills and trees. To believe otherwise is to dilute the Godhead."
-Robert Pirsig, Zen and the Art of Motorcycle Maintenance
#3
01-05-2003, 06:39 PM
 Caleb Fulton Z = Z^2 + C ......WHEEEE! AKA: aXvXiA #0461 (West Side Boiler Invasion) Team Role: College Student Join Date: Dec 2002 Location: West Lafayette, Indiana Posts: 205
question...

So serin/serout loops can be NESTED inside the main loop?
#4
01-05-2003, 06:40 PM
 Ryan Meador Registered User #0190 Team Role: Electrical Join Date: Jan 2002 Rookie Year: 1999 Location: Worcester, NH Posts: 68
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.

Last edited by Ryan Meador : 01-05-2003 at 06:43 PM.
#5
01-05-2003, 06:48 PM
 rbayer Blood, Sweat, and Code no team (Teamless Orphan) Join Date: Mar 2002 Rookie Year: 2001 Location: Minnetonka, MN Posts: 1,087
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
__________________
New C-based RoboEmu2 (code simulator) available at: http://www.robbayer.com/software.php
#6
01-05-2003, 07:20 PM
 Jnadke Go Badgers! #0093 Team Role: Alumni Join Date: Jan 2002 Location: Appleton, WI Posts: 775
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.
__________________
The best moments of our lives fall in two categories: those that did happen and those that did not.
#7
01-05-2003, 07:23 PM
 nwagers Registered User #0240 (Mach Vee) Join Date: Oct 2001 Location: Monroe, MI Posts: 88
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)
#8
01-05-2003, 07:30 PM
 Jnadke Go Badgers! #0093 Team Role: Alumni Join Date: Jan 2002 Location: Appleton, WI Posts: 775
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.
__________________
The best moments of our lives fall in two categories: those that did happen and those that did not.
#9
01-05-2003, 07:33 PM
 rbayer Blood, Sweat, and Code no team (Teamless Orphan) Join Date: Mar 2002 Rookie Year: 2001 Location: Minnetonka, MN Posts: 1,087
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.
__________________
New C-based RoboEmu2 (code simulator) available at: http://www.robbayer.com/software.php
#10
01-05-2003, 07:44 PM
 Mike375 Registered User #0375 (Robotic Plague) Join Date: Sep 2001 Location: New York City Posts: 46
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?
#11
01-05-2003, 08:09 PM
 Jnadke Go Badgers! #0093 Team Role: Alumni Join Date: Jan 2002 Location: Appleton, WI Posts: 775
Quote:
 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.
__________________
The best moments of our lives fall in two categories: those that did happen and those that did not.
#12
01-06-2003, 07:53 AM
 Ryan Meador Registered User #0190 Team Role: Electrical Join Date: Jan 2002 Rookie Year: 1999 Location: Worcester, NH Posts: 68
Quote:
 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.
#13
01-06-2003, 08:45 AM
 nwagers Registered User #0240 (Mach Vee) Join Date: Oct 2001 Location: Monroe, MI Posts: 88
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.
#14
01-06-2003, 10:35 AM
 Mike Soukup Software guy FRC #0111 (Wildstang) Team Role: Engineer Join Date: May 2001 Rookie Year: 1996 Location: Schaumburg, IL Posts: 762
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.

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

Last edited by Mike Soukup : 01-06-2003 at 11:08 AM.
#15
01-06-2003, 10:42 AM
 rbayer Blood, Sweat, and Code no team (Teamless Orphan) Join Date: Mar 2002 Rookie Year: 2001 Location: Minnetonka, MN Posts: 1,087
Quote:
 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".
__________________
New C-based RoboEmu2 (code simulator) available at: http://www.robbayer.com/software.php

 Thread Tools Display Modes Rate This Thread Linear Mode Rate This Thread: 5 : Excellent 4 : Good 3 : Average 2 : Bad 1 : Terrible

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts vB code is On Smilies are On [IMG] code is On HTML code is Off
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Announcements     User Announcements FIRST     General Forum         FIRST E-Mail Blast Archive     Rumor Mill     Career     Robot Showcase     Moderated Discussion Technical     Technical Discussion     Robotics Education and Curriculum     Motors     Electrical         CAN     Programming         NI LabVIEW         WindRiver C++         Java         MATLAB & Simulink         Python     intelitek easyC/REC information         easyC v2 for Vex         easyC for FRC         REC/Learnmate         WPILib         easyC PRO     Control System         IFI Control System         FRC Control System         Sensors         USB Chicklet     Pneumatics     Kit & Additional Hardware     CAD         Inventor         SolidWorks         Pro ENGINEER / Creo     IT / Communications         3D Animation and Competition         Website Design/Showcase         Videography and Photography         Computer Graphics     National Instruments LabVIEW and Data Acquisition         LabView and Data Acquisition Competition     Awards         Chairman's Award     Rules/Strategy         Scouting         You Make The Call     Team Organization         Fundraising         Starting New Teams         Finding A Team         College Teams     Championship Event     Regional Competitions     FIRST in Michigan     Mid-Atlantic Robotics     Off-Season Events         Chief Delphi Invitational     Thanks and/or Congrats     FRC Game Design     OCCRA         OCCRA Q&A         OCCRA Programming Other     Unsung FIRST Heroes     Chit-Chat         Games/Trivia             Fantasy FIRST     Car Nack's Corner     College & University Education     Dean Kamen's Inventions     FIRST-related Organizations         Western Region Robotics Forum         Robot Chicks Union (RCU)         Southern California Regional Robotics Forum         Hearing-Impared Network         FIRST Interactive Rural SupporT         freelanceFIRST         FIRST Scouting Network         openFIRST         The Grand FIRST Team         FloridaFIRST         Inspiration Foundation Inc.         South Dakota FIRST         FIRST International Partners         FIRSTwiki         Ultimate Robot Challenge         East Coast Drivers Union         Team San Diego         CollegiateFIRST         Dream FIRST         FIRST Brasil         The Blue Alliance             Video Archives     FIRST Historians     FIRST-A-Holic's Anonymous Mailbox     FIRST In the News...     FIRST Lego League         Lego Mindstorm Discussion     FIRST Tech Challenge         FTC E-Mail Blast Archive     VEX         VEX Robotics Competition     Televised Robotics     Math and Science         NASA Discussion ChiefDelphi.com Website     CD Forum Support         Bulletins and Newsletters     Extra Discussion Old Forum Archives     1999     2000     2001

 Similar Threads Thread Thread Starter Forum Replies Last Post What Should Be Done With Autonomous? xavior06 FRC Game Design 91 04-28-2005 06:00 PM How do you approach your animation? Koko Ed 3D Animation and Competition 7 01-27-2003 08:42 PM Autonomous Period Andy Grady General Forum 73 01-20-2003 08:34 PM EduRobot autonomy dlavery Robotics Education and Curriculum 3 12-02-2002 09:08 AM Proactive approach to scoring dilemmas reisser 3D Animation and Competition 0 07-02-2002 08:54 PM

All times are GMT -5. The time now is 01:21 PM.

The Chief Delphi Forums are sponsored by Innovation First, Inc.

 -- English (12 hour) -- English (24 hour) Contact Us - Chief Delphi - Rules - Team Site - Archive - Top