Go to Post I have long since stop trying to predict what the GDC will do. - FrankJ [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #1   Spotlight this post!  
Unread 30-01-2009, 13:10
Timshel's Avatar
Timshel Timshel is offline
Insane Web Coder
AKA: Mike
FRC #2037 (UCR)
Team Role: Webmaster
 
Join Date: Oct 2008
Rookie Year: 2008
Location: Germany
Posts: 4
Timshel is a jewel in the roughTimshel is a jewel in the roughTimshel is a jewel in the roughTimshel is a jewel in the rough
Basic autonomous on LabView

I'm not claiming to be the greatest programmer on the face of the earth, but I know there are plenty of other people like me who have never touched Labview before this competition and found it's design to be quite confusing, so I figured I'd share a few tidbits of wisdom. Any comments or suggestions are welcome.

To see how autonomous programming in LabView works, you must first understand what the "Watchdog" function does. When you activate the function, it starts a timer. This timer must be reset by the "Watchdog Feed" function before it runs out. If you do not feed it, the Watchdog will automatically shut down your robot when the time hits 0. This is mainly a safety feature, as if you didn't use it, your motors would continue running even if you lost control of the robot. However, a variation of the Watchdog function, called the "Delay and Feed" function, is also used for a more important purpose- autonomous coding.

"Delay and Feed" works much the same way as "Feed", with one simple difference. When the function is activated, it freezes the watchdog timer for a given amount of time, feeds it, and THEN moves on. Since this will delay the output of the error code that is required to run functions that take an error code as an input, you can use this to run those functions for specific amounts of time. Motor functions are what autonomous code mainly delays.

To get a better idea of what I mean, I'll post an example of a quick code I made a few days ago.



Note: This code was designed specifically for our robot, which I can assure you is powered differently than whatever you robot you are using. On top of that, it's a rather rough design that does not turn precisely on slippery surfaces. However, the program will function to some extent, and is a heck of a lot better than just standing in place.


Here's an explanation of what it does, step by step:

1. The two globals, "WatchdogDevRef" and "RobotdriveDevRef" are loaded into the VI. These variables are necessary to connect their respective functions into a "stream" that will activate one after another.

2. The globals pass into the main case structure for autonomous mode. This will always activate if the little "true/false" constant is set to true, which it is. It is essentially an "on/off switch" for the entire autonomous mode.

3. The two main pink wires are wired into a "Tank Drive" box and a "Delay and Feed" box at the same time. However, the Delay and Feed box will not activate until the Tank Drive command is done because it has an error-in input (the yellow striped wire) that come from the an error-out output of the tank drive command.

4. Using constants, the tank drive command activates both motors to go forwards at maximum power (set by constants). Once this is sent to the robot (and the error-out data is sent), the "Delay and Feed" command activates, which delays output of the "error out" data for 75 milliseconds (also set by a constant). The motor will continue running at max speed until given other motor data, even through the watchdog function.

5. Once the 75 millisecond timer finishes, the error out data is sent to the next Tank Drive function inside the While loop. This loop will run infinitely until autonomous mode is manually shut off. The robot is told to set the right motor to max power and the left motor to full reverse. The error out data from that function is then sent to the Watchdog, which delays the error output again for 10 milliseconds. Once again, the Watchdog is used to set the timing of the robot by not allowing the NEXT function to run until that timer has finished.

I repeat- the Watchdog is used to set the timing of the robot.

6. After the timer has finished, the error output is sent to the tank drive inside a For loop, which is set to run twice. In brief, it is programmed to make the robot move in something like an "S" curve using exactly the same "run and delay" method described above.

7. Once it exits the for loop, it is programmed to exit the for loop and restart the while loop again. This will have it once again making a small turn right and then doing the S-curve routine. This is repeated infinitely until someone manually switch it to tele-op mode, in which case this entire function will automatically be disabled.


Essentially, this is what you need to know:

-Autonomous mode can be replicated with the gray switch on the driver station.

-The Watchdog "Delay and FEED" function should be used after every single motor action to tell the robot exactly how long you want it to run.

-The "true/false" constant on the outer case structure is set to false by default. You must set this to true or your autonomous mode will not function.

-Data from sensors can be used to help the robot make dynamic decisions. The camera can be used to help it face an opposing robot's trailer, but you must create case structures to tell the robot when to make these choices.

-Make sure the function runs for an unlimited amount of time, as the judge will shut it off instantly when tele-op mode begins.


Some other tips to think about:

-Do not attempt to program your autonomous mode to "track" an opposing robot and shoot the balls within the first 20 seconds. You will inevitably fail, as it is virtually impossible for a robot with this kind of processing power to accurately chase down and line itself up with a moving object which can greatly vary in size and shape. You'd be much better off strategically to orient yourself in a good location for throwing as soon as you gain control, or at least to knock a few robots around before starting the match. Save the throwing for the human controllers.

-Seriously. Don't do it. It won't work. Think about at LEAST evading other robots instead.

-If you have access to an ultrasonic sensor, use it. It is amazingly effective for avoiding walls. The camera is NOT a substitute for this device, but it can be used to reorient yourself in a pinch.

-Learn the loops as soon as you can. Case structures and for loops are extremely important.
__________________
down down do that thang
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

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

Similar Threads
Thread Thread Starter Forum Replies Last Post
High CPU Usage in LabVIEW even with Basic Code Elliot Swart Programming 5 28-01-2009 08:44
Autonomous mode in Labview PinionTwister NI LabVIEW 3 10-01-2009 12:50
Autonomous questions (Labview) and some general issues Daniel_H NI LabVIEW 15 08-01-2009 21:07
Basic Labview Programming Questions comphappy NI LabVIEW 20 13-10-2008 18:29
New to C but not to basic, need help on autonomous cdennisxlx2 Programming 4 02-02-2005 03:38


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

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


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi