Thread created automatically to discuss a document in CD-Media.
FRC Team 836 RoboBees full release of Ultimate Ascent LabVIEW code
by: Richard100
_The RoboBees 2013 FRC entry, Frizz Bee, is a from-the-Tower high goal shooter, differentially steered, normally aspirated 30-point climber, with a 3-disc Autonomous.
Description reviews the five major control sub-systems, a series of general purpose subVIs (freely offered for re-use by the FRC community!), and some additional capabilities._
FRC Team 836 RoboBees full release of Ultimate Ascent LabVIEW code
The RoboBees 2013 FRC entry, Frizz Bee, is a from-the-Tower high goal shooter, differentially steered, normally aspirated 30-point climber, with a 3-disc Autonomous.
Major systems are:
Drive control – Provides for robot translation and rotation (skid-steering) and Sonar-assisted positioning for auto-arriving at optimal shooting location. Drive encoders are logged to an odometer file for transmission maintenance scheduling.
Fire control – Uses custom Infra-Red break-beak sensors to automatically manage game-piece positioning, always promoting a disc to the shooter from the queue. This offloads management of all low-level disc actuators to a robot state machine, allowing the operator to focus on simple high-level tasks like Loading and Shooting.
Shooter wheel control – Uses Hall Effect sensor with Take-Back-Half control algorithm to maintain shooter wheel at commanded RPM. Normal shooting was at 4200 RPM, which the control loop could hold well within +/- 10 RPM. We would also score while hanging from each tower rung by progressively lowering RPM and Elevator pitch, should discs remain available after initiating climb.
Elevator control – Uses Absolute Rotary Encoder with PID control algorithm to hold disc launcher at commanded Pitch. Control loop would typically hold launcher at 30.5 degrees +/- 0.3 deg. Using an absolute encoder simplified control, ensuring the Elevator would always ‘wake up’ knowing its absolute position, no matter where it was left when last powered down.
Climb System control – Uses state machine and Incremental Rotary Encoder to provide manual or automated control of ascent actuators, and a current sensor (on climb motor) to confirm climb hooks are properly seated and taking load, before committing to fully transferring robot weight to hooks during climb sequence.
FREE Code modules:
Several LabVIEW subVIs might be worth a mention, were designed for general purpose application, and are freely offered for re-use by the FRC community!
Bump Counter (RoboBees) – This provides discrete stepped values useful as a joystick interface to a control loop. It will count the number and direction of joystick axis ‘bumps’ and scale the output accordingly. Intent is to provide the operator simple control and precise knowledge over exactly how far (s)he is changing from a baseline value. We used it to turn the operator’s joystick command into discrete control values for fine adjustment of Shooter RPM and Elevator Pitch. In implementation, bumps are automatically reset upon moving the drive.
Cheesy Drive (thanks Team 254 / Cheesy Poofs!) – This scales the driver’s joystick command to provide a more natural feel during turns, effectively making the radius of commanded turns independent of forward speed. We liked it.
cRIO MAC (RoboBees) – Useful if you manage two robots, this reads the MAC Address of the cRIO and sets a ‘personality’ flag, allowing the code to self-adjust to custom settings, accounting for any system differences. This way common development can proceed with a single LabVIEW project. It will adapt to reading MACs from both the 8 and 4 slot cRIOs, but you’ll need to edit the subVI to insert your own specific cRIO MAC addresses.
DEMO Lock (RoboBees) – A non-competition subVI, this lets us lock out dangerous functions (like mini-bot or climbing hook deployments), and slow down drive and shooting speeds to safer conditions, consistent with demonstrating the robot around people in off-season events. Demos are much better when the robot moves, but we don’t want to hurt anyone with a robot designed to operate on a closed field! You’ll need to edit it to use a Global named in your code, typically unlocked with a non-obvious control input.
JK Latch (RoboBees) – This is a code implementation of the positive edge-detecting ‘JK Flip Flop’ circuit. It provides two separate control lines (Set and Reset) to hold or change a T/F state (see web for more explanation, it’s a common circuit element). We used it in testing velocity profiling approaches.
Latch (RoboBees) – This will latch a Boolean True value upon a rising-edge, and then toggle the value upon subsequent rising-edges. We used it to create a toggle behavior for certain functions commanded from our gamepad user interface.
MA3 Revolutions (RoboBees) – This subVI monitors an absolute analog sensor output and reports position. It was designed for the analog US Digital MA3 (shafted) and MAE3 (shaftless) absolute rotary encoders, which produce a voltage of 0 to 5 volts relative to encoder position. Since these are continuous rotation sensors, the voltage ‘wraps’ between the 5 and 0 values each time the sensor crosses over the 360 degree point, resulting in a sawtooth wave output as the sensor is continuously rotated. This subVI tracks these cross-overs, effectively providing a straight line output response representing position over multiple turns. Just watch your rotation rate (see subVI block diagram notes). We used it last year to sense our turret position – this year our Elevator application didn’t require it since all movement stayed within one sensor rotation.
Pulse Stretch and Delay (RoboBees) – This will trigger a Boolean pulse upon receiving a Boolean rising-edge. Both the pulse width and delay (in seconds) are adjustable. We used it to condition our break-beam sensor output and control the kick duration of our pneumatic disc actuator.
Ratchet Brake (RoboBees) – This is a motion control state machine for managing a ratchet mechanism. It controls the locking servo position to enable ratcheting in one direction, and momentarily reverses direction to free the ratchet lock when opposite rotation is commanded. Since we used an electric motor for our upper climb hook, the ratchet ensured that the motor would not back-drive should power be interrupted during the climb (at match end, for example) … acting as a tower fall-prevention measure.
Soft Stops (RoboBees) – This monitors a continuous sensor reading (like an encoder) to prevent a mechanism from being driven past hard limits. A definable ‘slow margin’ protects the mechanism from over-travel by automatically reducing speed (managing momentum) when near a hard limit. We used it to precisely position our encoded climb hook for ascents.
Stable (RoboBees) – This will monitor a Boolean input for a True transition, and maintain a Boolean False during an adjustable evaluation period (delay) until the stability of the Boolean input is confirmed. It was designed to ‘de-bounce’ ONLY the rising edge of a Boolean pulse. We used it as a Steady-State Detector (SSD) for both the Shooter Wheel RPM and the Elevator Pitch control systems. This is accomplished by first tolerance testing the sensed RPM, for example, and then testing the resulting Boolean value’s stability.
A Steady-State Detector effectively separates transient conditions from steady-state conditions (transients like initial shooter wheel spin-up and spin-downs from momentum transfers to a disc). An effective SSD is just as (or perhaps, more) important than the associated feedback control logic. Knowing if we’re at steady-state enables us to deny disc launches when conditions are incorrect, in both Autonomous and Tele-Op, while still allowing the fastest possible shooting.
The Stable subVI was also used to condition our Sonar thresholded output for precisely auto-locating the robot at the optimum shooting location.
Stable Rise and Fall (RoboBees) – This will monitor a Boolean input and maintain a Boolean level (T/F) during an adjustable evaluation period (delay) until the stability of the Boolean input is confirmed. It was designed to ‘de-bounce’ BOTH the rising and falling edges of a Boolean pulse. We used it to de-bounce our break-beam sensor outputs.
tbh (Take-Back-Half, thanks Team 123 / Cosmos!) – This is a highly useful velocity control algorithm that is easy to tune (one parameter) and fast reacting. We migrated from a PID to TBH, between our first and second regionals, to improve our ready-to-shoot time in Autonomous (~2 sec) and shot repetition rate in Tele-Op (
robot_code.zip (4.94 MB)