Beta Testing 2016 Changes to the Control System

The control system stays the same for 2016, but there is still annual Beta testing of software updates and changes, as well as, hardware/firmware upgrades. We also follow the ScreenSteps documentation for teams closely and look for improvements that might be made. ~75 Beta teams each receive different combinations of hardware, so one team may have the new radio while another gets the new CTRE magnetic encoder to test. Some of the notes that follow may need revision when we get our collective hands on the final product.

Goals of the Beta Test:

• Give a sizeable group of diverse teams early hands on exposure to the 2016 control system software;
• Use Beta Team feedback to refine/develop supporting documentation and training materials;
• Test the new features and functions of the control system to uncover problems and provide solution suggestions;
• Develop a supporting network/knowledge database about the new features;
• Allow teams to become "Control System Experts" and serve as area leaders to mentor other teams;
• Share information to minimize strategic advantages;
• Understand the difficulties and issues that Teams may encounter with the new control system features.

Software changes to be reviewed and tested include:

• LabVIEW migration to the latest LabVIEW 2015 product
• C++ & Java WPIlib rewrites
• Network Tables complete rework
• New roboRIO firmware
• New roboRIO image

Hardware changes to be reviewed and tested include:

• New robot radio - Open Mesh OM5P-AN Dual Band 2x2 450 Mbps Access Point
  • Info
  • Specs
  • Login for special FRC team price
• New VRM - looks the same with minor circuitry upgrades to make the 12v circuit more robust in readiness for the new robot radio
• CTRE Magnetic encoder, usable directly by the roboRIO or via a TalonSRX

Differences (or not) of note from the 2015 season control system:

• New robot radio:
  • Much smaller footprint 1.25 x 2.75 x 3.75" vs the older DLink size of 1.25 x 4.5 x 6"
  • Uses the same size barrel connector
  • Radio is 12v NOT 5v, so it will get wired to the opposite side of the Voltage Regulator Module (VRM), than we are accustomed to.
  • Fewer Ethernet ports - (2) rather than the old (4) ports, one for the roboRIO connection, another for either IP camera or Ethernet tether (can still use USB tether).
  • When adding the OM5P-AN to an existing network, the entire network will upgrade to 5xx firmware
  • Radio pulls ~200mA on bootup and ~180mA steady state under normal robot operation (Ethernet to roboRIO, IP camera streaming 30 frames per second at full res/50% compression, wireless to Driver Station PC)
• The mDNS name scheme has changed to "roborio-team#-frc.local". e.g., roborio-358-frc.local
• VRM v1.4 has more robust 12v overcurrent response.
• LabVIEW adds a Command set capability, similar to the Java/C++ Command framework
• C++/Java SmartDashboard gets a rewrite

FRC 358 Beta Testing photo gallery:

Just some photos of test setups, components, and the like.

• Photos from our Beta testing - Fall 2015
• Fall 2015 Beta Testing Videos

Radio notes:

• OpenWrt
• Special FRC firmware
• Default IP: 192.168.1.1
• FRC IP: 10.te.am.1
• Make default login: root/root

Radio specs:

• Speed: 450 Mbps (150 + 300)
• Radio: 1 x 802.11b/g/n 2.4GHz + 1 x 802.11a/n 5GHz
• Antenna: Three Internal (1x1 (2.4GHz) + 2x2 (5GHz) positioned lengthwise along the 3 sides where the ports are not.
• Power: 19 dBm (79 mw) flat power
• Range (approximate): 50-100' indoor (2-3 walls), 400' outdoor
• Processor: 520 MHz Atheros AR9344 MIPS 74K
• Width: 3.75 in
• Depth: 1.75 in
• Height: 1 in
• Weight: 0.52 lbs

Voltage Regulator Module (VRM) circuit upgrades:





VRM notes:

• New VRM is version 1.4 (older VRM was v1.2)
• No outside markings to tell the two versions apart
• Internal circuit board is marked with the version #
• New circuit board is black (older v1.2 is green)
• 12v circuit significantly beefed up and now handles overcurrents up to 2.8a where it consistently clamps. Power must be cycled to reset the clamp. Older VRM would clamp at progressively lower currents as it heated up. Overcurrent does heat up the module, and purposeful overcurrent is not recommended.