Making a Good FTC Control System

By Guinea Wheek

TL;DW

• This is a very long winded way for me to argue a future FTC control system
• Should be a single brick that everything (motor power, servos, sensors) plugs into
• And has the motor H-bridges/servo power on board
• That is compact
• And has as low latency as possible while still providing good application performance
• And is designed for reliability
• Minimal number of wiring connection points
• ESD resistance
• Ability to handle shorted lines
• 5 or 6 GHz Wi-Fi or something else that is hard to screw up

What is FTC and why care

• It’s like FRC, but you cram it in an 18x18x18” cube and it’s 2v2
• Cheaper, smaller teams, robots, and events
• But equal amounts of student passion and technical skill spread over a longer season
• Mostly highschoolers! Program is not just middle schoolers with Tetrix kits! Sorry FiM
• Easier to get going a good FTC program than a good FRC program
• This one hits one personally
• Good programs cost less than going to a single FRC regional!
• I’m not the best person to pitch FTC just know I care way too much about it
• Just watch Gluten Free please: https://www.youtube.com/watch?v=i2g_b54MEFI

Cliffsnotes History of FTC

• 2005: FIRST, Radioshack, IFI make FIRST Vex Challenge using Vex parts and electronics
• 2007: Dean Kamen and Tony Norman get a messy divorce
• We get FIRST Tech Challenge and Vex Robotics Competition
• FTC still uses Vex stuff for the 2007-2008 season
• 2008: we get Pitsco Tetrix and the Lego/HiTechnic system
• Worst trade deal in the history of trade deals, maybe ever
• 2011-2014: Gradual introduction of unlimited raw materials
• 2014-present: Unlimited COTS
• Tetrix dies instantly (competitively)

​

One of the last good Tetrix teams ever –>

Cliffsnotes History of FTC (post-Tetrix)

• 2015-2016: Modern Robotics introduced
• Bad
• Used USB-A and Micro/Mini-B for like a million connection points
• But at least we have kits like Actobotics and goBILDA now
• 2017-present: Rev Robotics
• First reliable control system since Vex era
• 2020-present: Post COTS
• Fabworks is cheap, who needs c-channel anymore?
• 2027: Who Knows?
• ?????????

But what do FTC teams want in a control system?

Well, in no particular order:

1. It needs to be reliable.
• Nobody likes dead robots.
2. It should be easy to wire and debug
• If there’s a place to screw it up, people are gonna screw it up.
3. It should be as low-latency as possible.
• If control loops take too long to respond, you react slower to things and are slower overall
4. It should have enough compute performance to do interesting things.
• Teams want to explore computer vision, ML, path planning, and MPC so an FPU helps.
5. It needs to be as compact as possible.
• You’re trying to cram everything into an 18” cube and the last thing you need is to fit half a dozen 4” pucks all over your robot. It’s much nicer if it’s preferably just one brick everything goes into.

Reliability

Robots don’t quit, but yours did!

Reliability

• Can’t score if you can’t move
• Priority zero in “effective robotics strategies” or whatever that one Canadian sports statistics guy keeps talking about
• Nobody likes disconnected robots
• Shocker

Wiring for reliability

• Centralized setups > distributed setups always!
• Less wires and less points of failure
• More compact (critically important in FTC)
• Way easier for the average team
• Also will win on latency
• Use quality keyed and locking connectors!
• Make it hard to wire things backwards
• And easy to use (not screw terminals)
• Connectors should be durable (not Tamiya or XT30…thanks Pitsco and Rev)
• Don’t use USB-A/MicroB/MiniB please
• Pay attention to connection cycles and wear-out!
• Particularly bad for USB
• Be able to recover from unreliable wiring (when reasonable)

Never again.

Vex V.5 Wiring Diagram (good)

PIC Microcontroller

Everything plugs in here!

16x dual digital/analog I/O

6x interrupt pins

(encoders, ultrasonic)

115200 baud UART for programming

7.2V NiMH battery

8 PWM pins for Vex 292 motor / 269 servo

2A max per port

4A across all ports

​

P = IV = 7.2V * 4A = 28.8 W ≈ 1 NeveRest

75 MHz receiver (x2)

75 MHz xmitter (x2)

Can direct tether to robot in place of receiver

​

FMS

(enable/disable signal)

Direct RJ12 tethers to robot on practice field

​

In-match RJ12 connection

​

HiTechnic/NXT Wiring Diagram (bad)

Samantha USB Wi-FI Module

HiTechnic SuperPro Prototype Board

Motor and servo controllers can be daisy-chained as shown.

It’s pretty much all one shared I²C bus.�

Up to:

• 4x DC motor controllers
• 2-4x servo controllers�

could be reasonably found on a robot for the 8 motors and 12 servos.

(Extra servo controllers == more current)

​

Pretty bulky!

Lego NXT Servos

HiTechnic

I²C sensors

3rd-party analog/digital sensors w/ custom circuits

Credit: Techhexium (FRC 4159) and Bill_B (FRC 2170) from https://www.chiefdelphi.com/t/programming-minibot/107688/43

​

Modern Robotics Wiring Diagram (crime against humanity)

​

I2C

Analog

Legacy I2C

Digital

12V motors

+ encoders

6V PWM servos

Wiring Control Systems Is My Passion

Image credit: Modern Robotics (now Boxlight)

Typically

2-3x

Typically 4x

1-2x

Typically none

Rev Robotics Wiring Diagram (good)

Current FTC control system

​

It looks complex but i assure you it’s mostly because this is a complete diagram

​

(Most teams won’t use Spark Minis, especially with two hubs)

​

No OTG cable, only RS485 between hubs

​

Mandatory for 2024-2025 season

​

Diagram credit FRC 3161/Stefen Acepcion

​

​

Reliably connecting to the field

• In the beginning, we were using 75 MHz with Vex PIC
• Hard to screw up
• Reconnects instantly
• Only one way and not that secure
• Synchronized FMS start/stop
• This was a good system!
• But incredibly inconvenient for teams
• Need to juggle crystals, tethers when not in matches
• No telemetry
• Need one receiver per driver (so 8 unique crystal pairs for a whole match)
• Also limits how many matches you run simultaneously in a venue

Reliably (dis)connecting from the field

• With HiTechnic, we emulated central FMS like FRC
• USB Controllers plug into laptops -> FMS -> Wi-Fi -> Robot
• Done over 802.11g via the Samantha Module
• Imagine an OMAP but really bad
• Paired with an FMS that makes the barrel jack look good
• Notoriously unreliable!!!
• It and the NXT hated any ESD at all
• Combined with unreliable FMS software
• Basically normalized disconnects via ESD or Wi-Fi failure as just a Thing That Happens To You In FTC
• Fairly common to see matches replayed because literally everyone disconnected from the FMS at every level of comp
• Still somehow better than using Bluetooth in 2010
• “If you disconnected 20% of the time with Samantha, it was 40% with Bluetooth”

/r/FTC meme i made in highschool

The compromise: FMS-less Wi-Fi

• Modern Robotics/Android introduced Wi-Fi direct
• No FMS
• Good for reliability
• Bad for match timings
• Ran at 2.4 GHz so you’d still disconnect at large events
• We fixed this with Rev
• 5 GHz
• Actual Wi-Fi access points
• Still possible to ESD the Wi-Fi radio due to lacking USB isolation
• In conclusion
• Wi-Fi 5/6 GHz good
• Revive the central start/stop signal with driver hub Ethernet?

FMS port????

Withstanding ESD and wiring events

• FTC robots are Van de Graaff generators!
• Very staticy machines
• Every port is hostile!
• There will be ESD events on digital/analog/I2C/quadrature/PWM/USB/whatever lines!
• You should be able to tolerate these
• And not randomly reset the moment a robot touches a field wall
• Don’t skimp on the TVS diodes!
• On both your robot controller and your sensors
• Or you will repeat the mistakes of HiTechnic and Modern Robotics
• And make everyone disconnect in half their matches
• Isolate your Wi-Fi radio signal lines from external lines!
• Rev didn’t do this and now you can disconnect from USB webcam ESD!
• Also internal Wi-Fi radios == less surface area for failures and easier to use
• Have reverse polarity protection!
• The $500 you saved out of School Team #6’s $800 budget after their Bad Soldering Job will never be forgotten
• Don’t bring us back to the era when disconnects were expected!

Designing reliable motors

• 12V motors need to be reliable
• These are the drive and main actuation motors FTC teams use!
• Typically 4 on drive, and 3-4 on mechanisms
• Otherwise teams will spend eternities working around you
• While cursing your very existence

The Tetrix 12V DC Motor :(

• Burnt out in just 7 seconds of stall!
• Actually just a 9v motor with a resistor?!
• Can break these just by reversing directions too quickly
• Teams accumulated buckets of dead motors
• Tetrix sold fused cables to try and stop dead motors!
• 152 RPM spur gearbox (2.6 FPS w/ 4” dia, common drive ratio)
• Slow and rather fragile (despite multiple revs!)
• Required external encoders for feedback
• E.g. USDigital E4P (kind of expensive!)
• Teams drove slowly and delicately to avoid obliterating terribly-designed motors!
• “FTC is so slow and bulky” Yeah cuz the motors sucked
• Condolences to those who made an FRC 2011 minibot

Credit: Jacob’s FTC forum thread: https://ftcforum.firstinspires.org/forum/first-tech-challenge-community-forum-this-is-an-open-forum/teams-helping-teams-parts-and-materials/2193-motor-teardown-failure-analasys

​

This drivetrain is designed to still run even if one of the Tetrix motors dies per side

Also note how it’s geared at ~75 RPM (whopping 1.275 FPS)

Still went to Champs!

The AndyMark NeveRest (good)

• In 2014 AndyMark NeveRest introduced
• “Drop-in replacement” for Tetrix motor at cost of being longer
• ~3 minutes under stall until failure (vs. 7 seconds)
• Built-in encoder on back (no need to buy external ones)
• 28.8 W peak power 6000 RPM free speed, 10A stall
• More powerful than Tetrix motor
• It’s actually 2x more powerful than what AM says it is
• Motor OEM silently made them 2x more efficient lol
• Initially just 40:1 spur gearbox, nowadays 20:1 planetary gearbox
• It and similar 550-class motors still standard today
• One of the best things to ever happen to FTC
• Like going from CIMs to Brushless if they saved teams money and never broke
• Critical Support to Andy Baker
• Please don’t force brushless on us

Credit: Cougar Robotics FTC 4251

Powering Servos Reliably

• Servos are a critical part of FTC
• Used in claws, indexers, sticks, flaps, angle adjusters, shooter hoods, small turrets, linkages, basically small actuations that aren’t major linear extensions
• Powered and signaled off of 3-wire DuPont connector PWM
• We get 12 of these
• Teams will draw every ounce of power out of them
• Typically 6v @ 4a max — the max current rating for DuPonts
• Future might consider 7.2-7.4V though 2024-2025 edit: the future is now thanks to the Rev Servo Hub
• Will draw insane transients!
• Don’t skimp on the capacitors!

The Servo Killer 9000

$200 servo that hates living

Case study: Rev Servo Power Module

• Takes 5v PWM signals and outputs 6v PWM with up to 4a current
• Made for both FRC and FTC
• Does the job decently well
• Can act flakily under too much load
• Increasingly powerful servos deliver harder transients to manage (thanks Axon)
• Exposed screw terminal power is…unique (great i need to crimp things now?)
• …Interesting ground plane mechanics
• Questionable zero signal behavior
• Some servos will return to home if they have no signal but still have power
• Rev hubs will turn off both power and signal when disabled to avoid this
• But SPM will keep supplying power, even if there’s no signal
• Can (and has) lead to damaging mechanisms!
• For the longest time, this was undocumented!
• QC issues
• Exploding power FETs on newer batches
• One batch just kept repeating the last PWM output on input signal loss
• Lot of these issues could be avoided with proper design
• This thing uses a whole PIC16 in it. This could’ve been done with passives.

Miscellaneous reliability things

• Have thermal protections where appropriate
• Motor controllers make more sense built into the robot controller
• External controllers == more bulk and points of failure
• FTC does not have that much power draw. You can fit the H-bridges into a pretty small place
• H-bridges generally don’t fail in FTC if designed right
• Ideally use USB-C if there’s USB at all
• And have it lock
• Again, centralized > distributed
• Operating systems should be designed for purpose
• Recovery times (e.g. radio reboot/external module reconnect) should be quick

Performance and Latency

Fast autos are fun!

What do autos look like when your control system sucks?

• They spam lots of sensors.
• When everything is slow, you don’t have to be too picky about what you use.
• More sensors ⇒ more Control Award ⇒ more overall awards perf ⇒ more Inspire nom chance
• More Inspire nomination chance ⇒ more advancement when ½ slots are Inspire runners up
• Just like California FRC regionals! Yay!
• They’re fairly slow.
• Potato nature of Lego NXT means you’re not doing much more than point and turn maneuvers
• NXT also used I2C bus for everything
• Don’t want to stall Tetrix motors ever (7 seconds of stall)
• Emphasis on completing all tasks rather than cycling extra elements

Landroids 2012/2013:

Top-level competitor at Championships for robot performance and Inspire

What can autos look like with a good control system?

• Autos can be way faster and complicated
• With motion planning and more advanced controls
• And more fun to watch
• Fewer, but more focused sensors
• Higher update rates are demanded out of sensors
• Deadwheel odometry wins in update rate race
• Currently fastest and most accurate way to localize
• Drivetrain encoders just don’t cut it at FTC scale
• AprilTags are new this season
• Can be used to correct deadwheel drift

← Typical deadwheel setup

Application Processor vs. Microcontroller/FPGA

• Aka “why we don’t use a Raspberry Pi”
• Application processors:
• Lots of power (enough to run Linux/computer vision/your path planning/etc)
• Your “robot code” runs here like WPILib
• Not a ton of GPIO itself (usually not that fast/high latency)
• Microcontrollers (MCU)/FPGAs (I/O processor):
• Not a ton of raw processing power (typically don’t run MPC on this)
• Lots of GPIO that it can access fast (analog/digital/PWM/etc)
• Dedicated peripherals (timers, counters) necessary for things like PWM or quadrature
• DMA controllers on those pins
• Most control systems use an application processor stapled to an FPGA or series of MCUs
• Typically you only want one if possible!
• Distributed systems are hard to do right (and have never been done right in FIRST)
• Ideally want to communicate with MCU/FPGA segment over fast memory-mapped I/O!
• Choice of interconnect matters!

Case study 1: roboRIO

• Powered by Zynq 7020
• Dual-core ARM Cortex-A9 app processor (RPi1-tier)
• FPGA over AXI used for DIO/analog/PWM/I2C/SPI
• All in one SoC package
• Interconnect: great!
• AXI is fit for purpose here!
• Just ignore NI-CAN
• I/O latency: good, mostly
• Ignoring how NI FPGA gateware is LabVIEW (so the MMIO sometimes eats glue), it means that reading/writing periphs is measured in microseconds
• Yay AXI
• Application performance: lacking
• Cortex-A9 is pretty anemic in 2023 but at least we have a double-precision FPU

Case study 1.5: Early 2000s IFI PICs (FRC and FTC)

• Used PIC18F8520 as application and I/O
• Interconnect: nonexistent (good)
• App processor is your I/O processor
• I/O latency: good
• Because it’s just direct GPIO on the PIC, and it has interrupt lines (no interconnects)
• Application performance: bad
• Barely able to run PID with fixed-point math, because PIC18F is a potato

Case study 2: Lego Mindstorms NXT + HiTechnic

• App processor: Lego NXT
• Atmel AT91SAM7S256 ARM7 from like 1998
• I/O processors: various
• Various HiTechnic motor, servo, sensor controllers. Also Samantha Wi-Fi USB (PIC32)
• Interconnects: bad
• I2C bus for everything
• I/O latency: bad
• I2C is slow, and the NXT is slow
• App performance: bad
• Atmel chip is just a potato
• No FPU
• Massively limiting for control complexity
• But at least we have PID on the motor controllers

I could use a cRIO for temporal fairness with NXT but it’s pretty similar to the roboRIO’s strengths just with a worse app processor (it uses a PowerPC softcore implemented in the FPGA, rather than a hard-core)

Case study 3: Modern Robotics

• Powered by Android phones + various Modern Robotics modules
• More application power than roboRIO
• Interconnect: bad
• It’s all UART over USB – not even real USB
• Everything is using FTDI chips
• I/O latency: bad
• Not as bad as I2C for everything though
• Android also causes issues
• Application performance: good
• RPi3-tier performance (Cortex-A53)
• Can actually run OpenCV on it
• Basically opposite problem from Rio
• Would rather have Rio tbh

Case study 4: Rev Control Hub + Expansion Hub

• Currently used FTC control system
• Powered by:
• Rockchip RK3328 (Control Hub app processor)
• Texas Instruments TM4C123GH6PGE (I/O actions)
• Interconnect: inconsistent and very mid
• Control Hub RK3328 to TI chip uses UART
• Control Hub to Expansion Hub uses RS485
• Not as good as AXI or PCIe
• Wish things didn’t have to be external
• I/O latency: not terrible but not good
• Can drive >200Hz updates…on the Control Hub half
• Only select interfaces are “fast” (cuz of bulk reads)
• Application performance: good
• Still RPi3-tier performance (Cortex-A53)
• Marginal improvement over Modern Robotics
• Still wins on better overall integration by a mile

Architectural conclusion: Rio with more power?

• An FPGA SoC with at least Cortex-A53 performance will work here
• FPGA can also be external, just use PCIe or AXI, not UART or I2C
• FPGAs have other advantages:
• Can change gateware to fix things like I2C or add new features (if done correctly)
• I2C register poller (more on this later)
• WS2812 Addressable LED support in FRC
• Aren’t limited by peripheral counts on an MCU (like an STM32 or a PIC)
• You just make the peripheral in Verilog or whatever
• This is a problem with Rev Expansion/Control Hubs currently
• Half the encoder pins count using software interrupts instead of a hardware pulse counter, so they just don’t count as well especially at high RPM
• Has implications for robot localization in FTC
• Opportunity for students to learn about digital design
• User partitions can be done securely with correct design work
• Downside: cost
• You may have to go Shenzhen dumpster-diving or go rizz up Xilinx to get them cheaper
• This also won’t fix all latency issues ever
• There’s still I2C

Polling protocols and I2C

• I2C is a powerful sensor interface for FTC
• IMUs, color sensors, distance sensors, etc.
• Only interface you can write data to sensors with
• But nobody likes it for high-performance applications currently
• And it’s slow, at least the way the Rev hub implements it
• You have to ask the Rev hub for data and polling for result
• LynxI2CWriteReadMultipleBytesCommand -> LynxI2CReadStatusQueryCommand
• Default SDK configuration will have a total transaction time of ~2-5 ms (ouch!)
• There are ways to cut this down to 1.5 ms between trigger read + poll for result
• I2C IMUs are still popular though (less prone to hardware drift)
• Only ones that integrate angular rotation are workable though (like BNO055 or BHI260)
• But many I2C IMUs expect you to integrate the angular velocity yourself!
• Popular request to vendors is to make analog IMUs…to work around this!
• Analog can be bulk read (fast)

There shouldn’t be a need for these things, yknow?

Fixing I2C (in FTC)

• Ideally want a way to asynchronously poll I2C registers continuously
• And then you can just read for the current value of (x) sensor’s register
• Can be complicated due to the way I2C operations can vary from device to device (effectively need to code in a protocol)
• May need some design work, but can’t be too bad, right?
• Modern Robotics CDIM had this async polling capability
• As bad as that control system was…
• They showed this can be done!
• This will open up more viable sensors for the program!

​

Conclusions on performance and latency

• It’s not just raw power
• But raw power is still good
• You also need good latency
• Have a sane application to I/O data path!
• Centralized architecture wins here too
• Don’t make us use CAN motor controllers pls
• More things that can’t really fit in here
• Fine details of deadwheel odometry
• Go out and learn how FTC teams currently use sensors
• Judge events! It’s fun!
• Your local PDP (probably) needs volunteers!
• You can also ask teams directly!
• You can ask me at guineawheek AT gmail.com
• Or on ChiefDelphi or Discord

FTC 11115 Gluten Free 2019 odometry deadwheels

(gm0.org)

← This man runs 2 dozen FTC events per season in Northern California and I don’t know how he hasn’t gone insane yet

The dream is one day…

• We get faster control of big 2-3 DOF arms in FTC
• Cuz they’re still kinda slow
• Instead we mostly settle for linear slides

Compactness

Yes it matters in FTC

Packing things in that 18x18x18” cube

• It’s hard to pack things into that cube in FTC.
• Motors take up significant amounts of space
• As does the control system itself
• And your drivetrain as a whole (hard to make wide intakes)
• Often need to fit linear extensions and complex handoffs to score
• Robots often have to expand to ~3x their nominal dimensions
• In my experience it’s hard for FRC designers to wrap their heads around this
• Custom gearboxes are too big, can’t just slap Falcons Krakens on everything, no pneumatics, even “small” actuators for auto take up big amounts of space
• Boxtube elevators are bulky and don’t extend far enough
• You should try designing an FTC robot sometime.
• Even at crayola cad level is informative

(this robot is actually 14x15x13”)

Control systems and bulkiness

• Only two systems have been good at this
• Vex V.5 PIC era (tbf it only had 8 servo-grade motors)
• Rev Control/Expansion Hub
• More distributed architectures have been more disrespectful to people’s space constraints
• HiTechnic/NXT
• Modern Robotics (worst offender here)
• People want that space for their mechanisms, not their electronics
• Also less wires == less points of failure
• Also lets robots look less boxy
• Common complaint of robots built between 2008-2018

Modern Robotics Tower of Ohgodwhy

vs. Fits Nicely In The Base

Size comparison: Modern Robotics vs. Rev

These have approximately similar capabilities!

​

Robot controller

​

8x 12V motors

12x servos@6v

​

1x IMU

​

1x Camera

​

Chonk

Gray: USB

Blue: I2C

Red: Power

USB connections realistically looked like this:

Dechonk

Gray: USB

Red: Power/PWM

Blue: RS485

Just for kicks: HiTechnic

• Gray: RJ12�
• Red: Power�
• Black: USB

You want ferrules.

Rev is pretty good in the packaging department…

• We might be able to do better
• There’s still the need for the Expansion Hub
• Ideally go without it
• Means you only have to source half as many chips…right?
• One board may be too bulky though
• Keeping everything on one board can help with latency/reliability
• But possible to keep these traits with correctly-designed interconnects to daughter boards
• Could even just be raw I/O pin connects to FPGA
• Maybe motor controller/servo controller sidecars?
• Featuring Lock-On Technology
• Distributed computing is hard!
• Let’s avoid it

Is this what peak performance looks like?

Core controller

Application processor + FPGA + Wi-Fi radio

Isolated USB ports for webcams/programming

3.3V Analog/DIO/I2C/Quadrature pins here

(Maybe PWM input?)

​

Could be made thinner

(wide for illustrative purposes)

Servo controller

+12V line

​

Outputs 6-7.4V

@ 4a per port

​

12 PWM pins from central FPGA

Motor H-bridge module for 12V

​

+12V line

​

8 PWM(?) pins from FPGA to 8x H-bridges

Overall conclusions

It Should Just Work™

Overall conclusions

• Centralized designs >>> distributed designs
• More compact, more reliable, less wiring, generally lower latency
• One Brick If Possible
• (I’ll settle for 1.5)
• Reliability still paramount
• We lived through non-functional control systems.
• Never again.
• It’s not just raw performance, latency matters too
• Compactness matters!

And that’s it!

• Thanks for listening!
• Please feel free to ask me about FTC control systems
• I am “guineawheek” on:
• Discord.com
• ChiefDelphi.com
• GMail.com
• Special thanks:
• Eeshwar for knowing more about Rev than I do (and for various lore bits)
• Every FTC team I used a photo of in here
• Further reading:
• The FTC Control System: A History
• This was the original “presentation”
• It’s less a presentation and more of an infodump lol
• [Insert rant about Blocks here and how it’s not a good visual programming language]
• https://blog.eeshwark.com/robotblog for Rev internals stuff
• https://learnroadrunner.com/ for how FTC teams do motion planning
• https://gm0.org/en/latest/ for a basic sense of how competitive FTC works