Difference between revisions of "DEWBOT VI Programming"

From DEW Robotics
Jump to: navigation, search
(→‎Autonomous Mode: 14/15-May-2010 work log)
(moving 14/15-May log to DB6 Programming Team page)
Line 18: Line 18:
 
====Autonomous Mode====
 
====Autonomous Mode====
 
:At the start of the match the robot has 15 seconds to try to score on it's own.  The plan sounds simple: Roll forward, find a ball, align the robot, kick the ball and SCORE!  In reality we need to move forward so far, use the IR sensors to find the ball, use the camera and the gyrocompass to find the target, use the drive system to line up the shot and fire the kicker. [[Glossary#easy peasy| Easy  Peasy]]!
 
:At the start of the match the robot has 15 seconds to try to score on it's own.  The plan sounds simple: Roll forward, find a ball, align the robot, kick the ball and SCORE!  In reality we need to move forward so far, use the IR sensors to find the ball, use the camera and the gyrocompass to find the target, use the drive system to line up the shot and fire the kicker. [[Glossary#easy peasy| Easy  Peasy]]!
−
=====Work Log from 14/15-May-2010=====
 
−
On 14-May into the wee hours of 15-May, [[User:Dreadknight | Paul Klufas]], Jack Rogers, [[User:ThatGirlFromConestoga | Jen Stanton]], [[User:Rizzo | Mike Rizzo]], [[User:Saffranhill | Faith McKown]], and [[User:Siri | Siri Maley]] (but mostly Paul) stayed at DEC to finish DEWBOT VI's first effective autonomous code (used at [[DEWBOT VI Monty Madness | Monty Madness]]). The following is Siri Maley's work log from that night.
 
−
<blockquote>'''Issue 1:''' motors will not run correctly at 13ft per 15sec (0.86ft/s). They do an (albeit very slow) St. Vitus's dance attempting to calibrate & end up ghosting throughout. (Theory) Motors can't seem to apply a steady voltage at that level and/or the module difference is too pronounced to handle.<br>
 
−
*Sol'n: run faster. 50% speed seems to be just about the minimum. Makes recocking between ball contacts difficult.
 
−
*To do: add deliberate stop-to-recock feature as necessary
 
−
'''Issue 2:''' looping kick cycle generates code commands for rapid-fire kicking. EDIT: cause determined in Issue 5 upon sensor voltage examination.<br>
 
−
'''Issue 3:''' IR sensor zero-point differs by robot location (initial testing vs various implementation locations).<br>
 
−
*Sol'n: up threshold & keep constant easy to change & integrate (proven through needing to change it a lot).
 
−
*To do: Check in situ.
 
−
'''Issue 4:''' IR sensor takes time to settle & can spike above threshold during this period. This can kick the kicker early & given (1) leaves it unready to kick at ball 1.<br>
 
−
*Sol'n: raise threshold (actually as result of 3) & pray. Attempted to add delay tonight but failed for unknown reasons (never exited delay mode). I've shut down further attempts for tonight--it's late.
 
−
*To do: add delay as necessary & possible. This seems to be becoming less of an issue as the night wears on (unknown reasons), but it's anyone's guess in the arena.
 
−
'''Issue 5:''' IR sensor reads kicker firing as a ball in place. Results in (what would be without the disable button) rapid-fire kicking. Wasn't allowed to happen very much -- no visible kicker damage. Major issue at first; though somehow (not deliberately) less of an issue later.<br>
 
−
*Sol'n: time heals all wounds?
 
−
*To do: only validate IR sensor reading when kicker is latched/limit switch is back. This was attempted briefly but did not succeed tonight for unknown reasons. I've again tabled further initiatives--it's really late.
 
−
'''Issue 6:''' Given speed from (1) and possessor issues, robot often kicks ball 2 and/or 3 out of place with a low-arc kick of ball 1. Depends highly on approach angle, contact point, and carpet (at least 1 of which probably explains with it didn't happen much on the rare occasions we've kicked in previously).<br>
 
−
*Sol'n: build up our karma.
 
−
*To do: implement stop prior to kicking as needed & possible.
 
−
 
−
'''Final code'''
 
−
*Kicked at least 2 balls each try for 3 tries in a row (missed 1 in 5 with no code change). Halts semi-sporadically (but not necessarily detrimentally, see  1, 4, 5, 6). Not wholeheartedly straight, but by-and-large contacts balls in useful location. Doesn't look particularly convincing, but gets more of the job done than before.
 
−
*Added teleop "ball in range" indicator for Classmate dashboard (currently ever-so-useful operator can watch this). No auto-fire in teleop yet. No vision, and what little code Ben tried suffered from (5) much more than Paul's. (Need to make sure any future testers also known they shouldn't just beat the thing up all day.)
 
−
 
−
'''Mechanical'''
 
−
*We're losing set screws left & right (also caused axle slippage). Loctited all that could be reached, centered axles & checked chains. Need to check consistently, especially 1 & 4...also 2 & 3.
 
−
*Removed battery box and cut top & bottom flanges (after first removing neoprene).
 
−
 
−
Many thanks and a job well done to Paul for not completely losing his mind.</blockquote>
 
  
 
====Teleop Mode====
 
====Teleop Mode====
Line 58: Line 30:
  
 
== How to Create a Custom Dashboard ==
 
== How to Create a Custom Dashboard ==
−
Instructions on how to create a custom dashboard in Labview. (Thanks Mark McLeod)
+
Instructions on how to create a custom dashboard in LabVIEW. (Thanks Mark McLeod)
 
*Exit the Driver account to close everything (Setup tab -> Exit)
 
*Exit the Driver account to close everything (Setup tab -> Exit)
 
*Login to the Developer Account
 
*Login to the Developer Account

Revision as of 14:52, 24 June 2010

Programming Overview

Programming for this years robot is more complex than any other year. While there are two modes, an autonomous mode where the robot drives itself and a teleop mode where roboteers drive the robot, there is a huge amount of shared programming.

The largest amount of programming is used to manage the drive train. As chronicled above we have a pivot drive. Each pivot has it's own drive motor to move the robot. By varying the speed of each wheel the robot direction can be changed. If you make the right side drive motors go faster than the left the robot moves in a gentle arc to the left.

The pivots also turn 360 degrees. Each pivot has it's own steering motor and a magnetic sensor. The sensor tells us what "direction" the pivot wheel is turning. So if we want to move to the left, we rotate the wheels 90 degrees to the left and apply power and the robot moves, looking like a crab. This is motion is call strafing, allowing us to quickly move side to side across the field.

The wheels can turn at any angle, allowing the robot to go in any direction. This crab like motion allows us to get to the ball while keeping the front kicker towards the goal. We strafe or crab over, align and kick.

On the fly we can change modes to "snake mode." This allows the robot to act like a snake going after prey. In our case the ball is the prey, snake mode keeps the ball in front of the robot (snake) while the back of the robot moves around. This allows us to herd balls into the goal.

Since the wheels can turn 360 degrees the robot can spin around on it's axis allowing us to reorient directions quickly.

Finally while there is a "front" on DEWBOT VI where the kicker is, as far as the drive system is concerned there is no front. If you rotate the robot 90 degrees to the right, what was the left side is now the front.

So it's like rubbing your stomach while patting your head while chewing gum while running!

Autonomous Mode

At the start of the match the robot has 15 seconds to try to score on it's own. The plan sounds simple: Roll forward, find a ball, align the robot, kick the ball and SCORE! In reality we need to move forward so far, use the IR sensors to find the ball, use the camera and the gyrocompass to find the target, use the drive system to line up the shot and fire the kicker. Easy Peasy!

Teleop Mode

This is where the two person drive team gets to show their stuff. They move the robot around, find balls and shoot them into the goal. Wait, that sounds like the autonomous mode, just use that. Well we do, the targeting system shows us where the goal is and when we are aligned. The reason the roboteers are needed is that under autonomous the balls are sitting still, now they are moving. And there is not just one ball there could be 12 of them on the field. Oh did we mention the other 5 robots?
So it gets a little wild and crazy and while our programmers are good, the roboteers drive the show. The robot is still doing a lot of work, it's doing the drive train, tracking the goal and automatically cycling the kicker. There is lots of teamwork going on!

Safety

Safety is important to our programming efforts. The initial robot code is responsible for enable and disable functions. It connects to the driver station and follows it's control sequences.

At the end of the match it is possible that the robot is in a armed state with the kicker pulled back. This represents a hazard to the people moving the robot after the match. When the robot receives the end-of-match signal it releases the kicker, allowing the robot to be moved safely.

How to Create a Custom Dashboard

Instructions on how to create a custom dashboard in LabVIEW. (Thanks Mark McLeod)

  • Exit the Driver account to close everything (Setup tab -> Exit)
  • Login to the Developer Account
  • Use LabVIEW and create a new Dashboard project.
  • You'll then need to create an exe
    • Right click on Build Specifications -> New -> Application (EXE)
    • In the Popup:
      • "target filename" - change the name to Dashboard.exe
      • Change the Destination Directory to "C:\Program Files\FRC Dashboard"
    • Tell it where to begin:
      • In the left list click on "Source Files"
      • Click on "Dashboard Main.vi"
      • Click on the right pointing arrow that will highlight
      • You should see Dashboard Main appear on the right hand side under "Startup VIs"
    • Click on "Build" at the bottom to create your exe
  • Login to the Driver account to start up the new dashboard and see if it works.

Labview links

FIRST Robotics Software 2010 - Windows - LabVIEW & NI Utilities - this is the initial release, Do not use the serial number that comes in the software kit for activation. You MUST use the following Serial Number to activate LabVIEW: L13R00000

Link to the FIRST FRC Software Page that has all the programming information on the 2010 software packages.

LabVIEW Tutorials to learn some LabVIEW

FRC 2010 Training Tutorials to learn the 2010 LabVIEW

FRC 2010 Driver Station to learn the 2010 Driver Station

FIRST Community National Instrument's FIRST Community

Programming Forum from Chief Delphi - Chief Delphi Programming

Retrieved from "https://team1640.com/wiki/index.php?title=DEWBOT_VI_Programming&oldid=8034"