DEWBOT VI Programming Team

Head Mentor: Foster Schucker - Mentor: Jon Davis

Student Lead: Paul

Team:

Kenneth

Nicole

Ben

Zain

DJ

PID Links

This section has some links from Chief Delphi and NI about PID functions and Labview.

There is a PID tutorial that comes with LABview.

Chief Delphi links

Article talk that the Labview function is the academic form, not the one we use normally

What the values in a standard PID do

A comment about the window steering motors and the backlash factor - description of backlash There is also a reminder about deadbands in the motors as they move the worm gear around.

(Is the Jaguar deadband an issue? Are we using the brake functions on the Jags? - Foster questions)

A really good discussion about PID and how one team is using it.

National Instruments links

LABView Tutorial on PID and the Advanced PID This is a good place to start

Full set of LABView Tutorials on controls - There is a link to PID on the page (right hand side, a few from the top

FIRST Wiki article on PID, there is a PID tuning applet link at the bottom

Other links

Article from control engineering on how PID's work. All the math is there

Programming Goals

Programming goals to accomplish:

1. Pivot Drive - Magnetic Encoder, Least Distance Turning (50%)
2. Pivot Drive - Twist Capability (needs twist controller) (10%)

FRC Team 1640 Programming Team

Journal for the Programming Team
Build Season 2010 "Breakaway" If you are a programmer, please add/edit. Repeat above, I mean it. If you are a programmer, please, please add more. I'm sure programmers did stuff week of 1/18-1/22!

2010 DEWBOT VI Game Code

Link to 2010 DEWBOT VI Game Code Page: 2010 DEWBOT VI Game Code

Programming Ideas/Goals

• Pivot Drive
  • Port to magnetic encoders
  • Recalculate math for all drives
  • Develop multi front chassis algorithm
  • Talk about innovative pivot drive usage
• Vision
  • Develop target tracking using camera (needs to work with something else other than arcade drive)
  • Develop line tracking (done)
  • Develop ball tracking (Need to know the sensor)
• Robot Safety
  • Develop anti flipping system
• Robot Itself and Kicker
  • Autonomous system with customization (part way done, need to know ball traking sensor)
  • Program kicker
  • Final tower climbing system
  • LED for signaling
  • Develop camera to kicker relationship
• Driver Station
  • Update Classmate PC
  • Design friendly control system with LEDs and toggle switches
• Lessons/Etc.
  • Pivot Drive
  • LabVIEW
  • Algorithm development
  • Programming management
  • Camera System
• Conclusive Paperwork
  • Detailed Documentation of Process and Code
  • Easy Driver's Manual
  • Nice demonstration PowerPoint

Ideas Discussed

Vision System

January 17, 2010

• Caged Camera for safety and protection
• Spring system that just knocks back or foward
  • Material and shape TBA
• Located in middle of robot
• Rotation and Altitude control
• Recalibratible camera
• Reuse of camera code instead of making more
• 3 Goals:
  • Target Tracking
  • Driver's Aid
  • Field Watcher

Tasks In Progress

January 17, 2010

• Vision system programming
• Pivot Drive math recalculations
• Remind Paul/Ken to update Classmate

January 29, 2010

Goals for January 30, 2010

• Have all drive modes ported over to game code (Kenneth)
• Work on XBOX Controller (Paul)
• Use recalculated math from Clem in code
• Develop theoretical algorithms for [Least Limit Movement Algorithm 2.0]
• Develop theoretical algorithms for "Crab with a Twist of Snake" "Crab with a Twist of UFO"
• Despite our mentors recommendation that we don't program the same code, we will be programming the same theoretical code. With that we will see which works best (survival of fittest) and compromise (natural selection)
• Have a working drive code by night of January 30, 2010. We've moved deadline from January 31, 2010.
• We need a twist control.

Tasks Accomplished

January 17, 2010

• Assembled successful Control System
• Tested out Control System
• Tested out Cherry Magnetic encoders and various light sensors
• Created power plug for camera
• Worked out some math for pivot drive
• Port most drive modes to 2010DEWBOTVI Code

Programmer's Journal

January 16, 2010

9pm-12am

• Set up control system
• Tore apart Pivot Bot Prototype
• Reimaged cRIO
• Installed drivers for Classmate
• Checked out Cypress First touch
• Talked about camera system (look above)
• Broke into vision and pivot crew
• Talked about drive math
• Tested out Cherry sensors
• LUNCH

1pm-5pm

• Tested out more of cherry sensor
• Tested out light sensors
• Worked on camera
• Went to RadioShack to buy H head for camera
• Solder plug and plugged in into power distrabution
• Realize need to update classmate

January 29, 2010

6:00 BPC (Before Paul Came)

• Kenneth and DJ arrives.
• Looked for power strips with Cole. There are none...
• Tried to get LabVIEW on DJ's Mac. No success.
• Started programming drive system.
• Programmer's cookie break
• Tried to get Max to come.
• Asked Clem about math for pivot drive. Success.
• Installed Cypress CD.

6:00 APC (After Paul Came)

• Paul arrived
• Discussed about status quo of code.
• Compromised code (survival of the fittest)
• Worked on XBOX Controller input .vi (Paul) Success
• Port pivot drive system over to 2010 DEWBOTVI Code
• Crab and Snake done. All other modes to be done (Kenneth) Success
• Paul and Kenneth decided on angle degree as base unit for crab.
• Discussed the [Least Limit Movement Algorithm] and seeing how to implement it
• Proposed new additional "limit" to [Least Limit Movement Algorithm], therefore upgrading it to [Least Limit Movement Algorithm 2.0beta]
• DJ still trying to install LabVIEW on Mac. Doesn't work.
• Paul and Kenneth worked on "Crab with a Twist"
• Departed ways

After Robotics

• 12:15 AM - Paul completes theoretical test of Least movement algorithm ;) Success

January 30, 2010

Pre Arrival

• Paul worked on update Least Movement Algorithm
• Kenneth worked on finalization porting and redoing math.

Arrival to Lunch

• ???

Lunch to Snack Break

• Traded code, compromised
• Talked about drive motors and rota motors
• Have working code

Snack Break to Dinner

• Talked about autonomous
• Drafted some autonomous

Dinner to Departing

• Worked on Math - Ben, Ken, Foster
• Math is complete and fixed
• Learned arrays to use for code

January 31, 2010

12 PM

• Paul finished Shortest Angle Algorithm

3 PM

• Kenneth and Ben finalized Snake and Auto array
• Paul fixes SAM.vi

7 PM

• Ben taught DJ LabVIEW
• Zain worked on his first code
• Paul finalizes Drive Motor.vi, Turn Target.vi, Crab Mode 3.vi, ShortestAngleMovement.vi
• Kenneth compromises all code together
• Waiting for the robot...

February 12, 2010

• Crab mode works!
• Ken is planning a snake mode.
• Tested Autonomous for Teleop, couldn't get past acquiring target.
• Regular Autonomous has yet to be tested (It is much different code than Autonomous for Teleop.)

February 13, 2010

Today we made great progress with the robot (Yesterday we made a lot too, programmers came in at 8:00 am and crab mode came to life)

• After some mechanical fixing-up, crab mode worked!
• Snake mode wasn't really tested, but it appeared to work up on blocks, so we need to test that tomorrow.
• Carly decided that she preferred the XBOX 360 controller over the twisting joystick
  • The twisting joystick works fine when moving forward, but when going backwards or to the side, the natural twisting motion of a person's arm takes over
  • The twist portion of the joystick is so sensitive that when moving to the side or backwards, it sees it as a twist
  • The XBOX 360 controller is quite sensitive on the joystick part, but we can cut it down to half speed, and then set it so that holding down a button makes it full speed
• We also found that the wheels sometimes align to 0 degrees, sometimes to 180 degrees
  • This can be explained by the chains always being on the inside, which would mean they flip, however, this doesn't mean too much since the magnets mounted for the magnetic encoders choose an arbitrary start position anyway.
    • This means calibration code - which we already have implemented
      • At the present moment, the code works like this: Take a reading when prompted to, and set that permanently as the calibration value
      • We need to change this so that it initially takes the value checks that forward is in fact 0, and then sets the value. If it is not 0, then it needs to correct for that. This should then fix the problems we've been having.
  • Though it is not a perfect explanation, I think it is at least part of the problem, especially since while we were testing today, we entered calibration mode while some of the wheels were reversed, and when we exited, some of the drive motors were spinning in the wrong direction.
• Hmmm...I forgot what the other thing we were supposed to is. So I'll keep this here as a placeholder just in case I remember, or if any of the other members edit this page and know what it is.
• On a final note, I'm planning (for fun) to bring in all my game controllers (DDR, Guitar Hero, XBOX 360 gamepad, Logitech Rumblepad 2 (generic gamepad), possibly the racing wheel) as well as to try to use my pen tablet to control the robot
  • This should be interesting!!

14/15-May-2010

On 14-May into the wee hours of 15-May, Paul Klufas, Jack Rogers, Jen Stanton, Mike Rizzo, Faith McKown, and Siri Maley (but mostly Paul) stayed at DEC to finish DEWBOT VI's first effective autonomous code (used at Monty Madness). The following is Siri Maley's work log from that night.

Autonomous Work

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.

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.
Issue 3: IR sensor zero-point differs by robot location (initial testing vs various implementation locations).

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.

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.

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).

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.

23-June-2010

Paul, Ben, Kenny, Jon Davis, Foster Schucker, and Siri Maley worked on and helped the programming team tonight.

Ball Detection

The night's main mission was to investigate ways to determine that a ball is in kicking position. This involves two degrees of freedom. The first is left-right, which is less sensitive (given the width of the kicker). The second is the ball's distance from the robot (on the longitudinal axis), which is much more sensitive, but can be addressed with an effective possessor. The current system utilizes a reflective IR sensor, but it yields highly inconsistent (rather approaching useless) values. For the next iteration and given previous experience, the team tentatively decided to place a lower priority on the former while attempting to address the latter. A brainstorming session produced the following ideas to begin examining.

Average Original Infra-Red Values

This is a simple approach aimed at decreasing the original IR sensor's sensitivity by using the average of n (currently 5) readings. This code was quickly written (and shared), but testing (as far as decreasing sensitivity and/or causing a delay) will wait until the trirol possessor prototype is complete.

Beam Break - Infra-Red

This idea involves using two VEX IR sensors, one with the the transmitter covered and one with the receiver covered. Paul is (has almost) finished the code for this, though it's not published yet. The prototyping was less promising, however, yielding overall inconsistent values (though these improved as work continued) and rather small broken vs non-broken average differences. Further prototyping is also waiting for possessor completion. Steel tubes have been suggested for mounting and confining the area of both the receiver (from ambient light) and transmitter (from detecting the ball before it's in position)

Beam Break - Visual Light

This uses the same theory as the IR beam break, but employs a VEX white light sensor and a light source. Source will likely an LED flashlight, though prototyping used a lantern flashlight. Basic prototyping (correct distance, correct sensor, approximately within the frame perimeter) yielded very promising results. Values appeared consistent and differentiated: 0.05±0.02 for unbroken and 0.5±0.15 for broken. Mounting, confining and testing needs to be addressed as with the IR beam break.

Contact Band/Limit Switch

This idea involves running a simple band across the front of the chassis. When a ball enters the kicking area, it depresses the band, triggering a limit switch. Prototyping on the proxy chassis (thanks, Matt) indicated minimal band displacement where a limit switch could be mounted. This would make the setup very delicate and also requires at least two switches (on for each side), not an optimal situation for the front of a FIRST robot. If pursued, this would use virtually the same code as the beam break.

Other Ideas

Other brainstorming ideas that weren't pursued that night include sonar (incorrect range), measuring possessor bar capacitance (how?) and measuring the load on the possessor motor (how?).

Other Progress

Ball detection is the last first-priority problem to address in autonomous. The n kick autonomous structure will work normally (as with the current IR sensor). Camera target acquisition is still a possibility (Paul is making progress), but remains a low priority until ball detection and angled kicking work consistently in competition. Autonomous code still does not incorporate line reading (though sensors remain mounted and some code does exist), which, given the past five competitions, is not so much a problem.
Code has also been written and shared for manual and semi-auto kick modes in the teleoperated period. In semi-auto mode, the driver presses the trigger and the kicker waits to fire until the sensor detects a ball. Manual override for this mode is button 10 on the operator joystick. Manual mode gives complete control to the driver, who may use the dashboard sensor indicator (line 2) to determine when to kick. [I do not know how to change modes. Need to get this information and confirm the rest with Ben. - Siri]
Finally, code has also been written and shared for third roller retraction. The third roller (who's solenoid is programmed for channel 5) should retract when the kicker is relaxed (to go over the bump) and extend when the kicker is recocked. In addition, pushing button 11 on the operator joystick alternative retracts and extends the roller. This acts as both a manual fail-safe and a kinder, gentler kick for herding/home zone scoring.

Task Summary and Contacts

Managing: Jon, Siri
0) Brainstorming: Paul, Ben, Kenny, Jon, Foster, Siri
1) IR Average: Ben (idea & code) - complete & shared code, not tested
2) IR Beam Break: Paul (code & prototyping), Jon (prototyping) - inconsistent basic prototyping, untested code
3) Visual Beam Break: Paul (code & prototyping), Siri (prototyping) - promising basic prototyping, untested code
4) Contact Band/Limit Switch: Paul (code from Beam Break), Matt (prototyping) - complete, prototyping not promising
5) Autonomous Framework: Ben (checking current code) - complete, shared (same as previous)
6) Teleoperated Manual & Semi-Auto: Ben (code) - complete & shared code, not tested
7) Third Roller Manual & Automatic Retraction: Ben (code) - complete & shared, not tested To-do) Have the entire drive team (including all alternates) understand and be able to readily use all information on and associated with the driver's station dashboard and controls. We are making progress here.

11-July-2010

Paul, Ben, Kenny, Clem McKown, Gary Deaver, and Siri Maley worked on/helped the programming team today. The mission of the day was autonomous. (Clem and Siri Vulcan death grip-ized the possessor before the programming party started.)

Problems Encountered

Wheel 2 Drifting

Relatively early in the process, wheel 2's steering motor started drifting continuously. After a troubleshooting meeting, the team settled on changing the victor to the one that used to run the possessor (on the theory that it had already proven itself). This fixed the issue, and upon removal we realized that the previous victor was old. Really old, unmarked in fact. We should check this in the future. We're unsure if the issue was simply due to age or if it was calibrated to a joystick with a shifted deadband. (If you're curious, that's not a good idea. Ask Gary for details.)

Wheel 2 Stuck

Later on, wheel 2 stopped turning entirely. Turns out the PWM was pulled out. This was checked (apparently second time's the charm), but we really need to keep an eye on these a well.

Drifting in Autonomous

The robot would not go straight (or at a 2.5° CW, or 9.5° CW, or 30° CW, for that matter) in autonomous when the angles were preset and left without active control. The solution seems to be reimplementing PID control, which means we have to set/confirm angles during autonomous (but this is not such a bad thing).

Dribbling

If we triggered the IR sensor(s) before the kicker was armed, it would kick immediately after latching, pushing the ball about 3ft forward. (It's marginally unclear why this happens.) Coincidentally, this is exactly the distance which allows the IR sensors to trigger just before the kicker is rearmed. Iteration ensues. We fixed this by implementing a 0.25s pause between arming and the first possible kick.

IR Sensor False Positives

The IR sensors would occasionally give false positives, likely a combination of luck and the varying color (reflectivity) of the room's carpet. (The latter is not such an issue at competition.) Enlarging the tolerance solved this problem. False negatives are also quite rare/nonexistent. In fact, both were nonexistent in at least the last 3 hours of testing.

IR Sensor Blind Spot

There appeared to be a blind spot where neither IR sensor picks up the ball. This seems to have disappeared, most likely from possessor improvements. (The ball shifts/compresses ever-so-slightly, but enough to reach out of the blind spot.) no failure in at least the last 4 hours of testing.

Final Results

Dashboard Signals: There are now dashboard signals that indicate the following

When a ball is possessed

Whether the possessor is in, out, or off

Both light sensor values

Autonomous

Near Zone, n=1: This is both accurate and consistent in kicking then near zone ball. Plus, it looks really really cool.

Mid Zone, n=2: This is mostly consistent and accurate, if not at scoring at least at clearing the bump. The kicks have a good arc and solid aim.

Far Zone, n=3: This is rather consistent at clearing at least one bump (2 if we get lucky bounces). Ball alignment can prove somewhat sensitive. Tape guides will help with this.

Sensors

On 10-July, the team (Clem, Gary, Scott, Rizzo, Paul, Matt, Doug, Siri) settled on two vertically mounted IR sensors pointing down between the possessor and the chassis frame. These work like a charm. We've found our ball sensor! Other ideas included an LED beam break, photo electric sensors, CAN on the possessor motor (it was even switched to a Jag to accommodate this), straight and U bumper bars, horizontal IR sensors, string triggers and large and small limit switches. All these were pretty painful, we're all glad this worked out.

DEWBOT V

Kenny and Ben got DEWBOT V working off their laptops, allowing us to driving V and VI simultaneously. We'll be taking advantage of this on Monday/Tuesday. Thanks guys!

---