OCCRA
Go to Post Don't let what you think you can do get in the way of what you can do. - Daniel_LaFleur [more]
Home
Go Back   Chief Delphi > CD-Media > White Papers
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

photos

papers

everything



FRC Team 836 RoboBees full release of Ultimate Ascent LabVIEW code

By: Richard100
New: 10-22-2013 06:53 PM
Updated: 10-22-2013 06:53 PM
Total downloads: 302 times


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 (

Attached Files

  • zip RoboBees 2013 LabVIEW Robot Code

    robot_code.zip

    downloaddownload file

    uploaded: 10-22-2013 06:53 PM
    filetype: zip
    filesize: 4.94MB
    downloads: 300



Recent Downloaders

Discussion

view entire thread

Reply

10-22-2013 08:29 PM

Richard100


Unread Re: paper: FRC Team 836 RoboBees full release of Ultimate Ascent LabVIEW code

Full text:

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 (<1.5 sec). Highly recommended.

Other Capabilities:
Quick-change parameters – Making parameter changes is time consuming when code has to rebuilt and reloaded, and time is short in the pit between matches. We developed an approach that stores critical parameters in an Excel file on the cRIO, which we may want to ‘tweak’. The file is initially accessed (usually while waiting for the match to begin) and copied into LabVIEW variables. A simple FTP to the Excel file allows quick parameter adjustment in the pit without engaging the lengthy code change and download process.

TDMS Data Logging – We used the LabVIEW Technical Data Management Streaming (TDMS) vi’s for time-stamped data logging during matches. This allowed us to closely monitor critical parameters such as Shooter Wheel RPM and Elevator pitch for each shot taken, and track sensors, gamepad inputs, and states for (every loop iteration of) the Fire Control System for diagnostics. It was also useful to create a stage-to-stage record of Autonomous execution. We compare the data timeline to our video record to discover and correct issues between matches.

Real-Time Design – This year we dabbled in Real-Time design, using Timed Loops for all time-critical processes, and attempting best practices to improve determinism (ensuring processes execute on schedule) by avoiding invoking the Memory Manager, disk I/O, and priority inversions from blocking operations associated with Globals. We moved from Globals to the Real-Time First-In-First-Out (RT FIFO) Shared Variable for jitter-free inter-process communication.

Use of the producer-consumer architecture was key to ensuring determinism during data logging. For time-critical loops, data transfer used the RT FIFO primitives to buffer communication. Queues were employed for the other non-deterministic loops. We also used a burst transmission approach on the consumer side for significant improvement in TDMS time efficiency. Overall results from Real-Time design improvements included elimination of jitter and decreasing CPU utilization from mid-90 % to less than 50%. Still learning.

The RoboBees will be at the Baltimore Area Alliance FRC Training Workshop this Saturday ... come see training sessions on Sensor Basics and much more!



01-03-2014 05:55 PM

adciv


Unread Re: paper: FRC Team 836 RoboBees full release of Ultimate Ascent LabVIEW code

Our 2012 robot code is provided here. Documentation to be improved in the future.

http://www.chiefdelphi.com/media/papers/2917



view entire thread

Reply

Tags

loading ...



All times are GMT -5. The time now is 01:42 AM.

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