Designing an FRC style brushless motor controller

Technical Control System
1

PRE POST WARING: This post contains the wishes and dreams of someone who is by all account not technically informed/trained/experienced enough (yet!) to make said wishes and have said dreams, specifically when talking about PCB design and writing software, and the technical challenges that come with it. This post, unless spun off (probable to happen, and I won’t stop it if it does), is targeting a lot more of the on-paper design that comes before hand.

With the advent of more and more brushless motor options coming to FIRST, it’s only a matter of time before we end up with a general motor ecosystem like we had before brushless, multiple motor options and multiple options to drive said motors, with general interchangeability between vendors. This begs the question, are there things the FIRST community is asking for in a brushless motor controller that is not yet available. Would these features need circuitry on the board, or does it only need software?

I ask this because, for better or for worse, I’m in the beginning research stages to develop my own brushless motor controller to emulate FRC style controllers. This project is a step down the line in a general wish to learn some more specific skills to add to my resume, specifically in the context of this project, PCB design and software/“firmware” development. Because this project is specifically aimed at emulating an FRC style motor controller, I figured I’d ask the community for a punch list of items they wish to see in a controller.

My background and degree is in mechatronics, industrial automation engineering, so I’ve got a lot of the general background knowledge one needs to take a crack at a project like this, specifically electrical theory and multiple classes and labs focusing on machine control and the safety that comes with designing control circuits and software. I’m currently gaining knowledge in PCB design during my internship.

I’ve been looking into the brushless motor driver ICs out on the market. Specifically TIs MCT8316Z, which on the face of the features list sounds like a driver meant for FRC applications, and from reading the data sheet, should be fairly easy to control from a micro controller (my current plan will make use of a COTS controller that plugs into board with the driver, I’m thinking a RPI-Pico/similar). The micro controller would then also be the vehicle in which to program/communicate with over CAN and handle inputs and outputs from a general data port for external control schemes (external limit switches/sensors/etc). In this way, a micro controller and this IC to me is no different (take that with a grain of salt) from a PLC and a VFD.

Then there’s the challenge of writing software to control the driver chip. When it comes to my own integration of this project, the firmware will most likely not be as finished as REV’s or CTRE’s software, nor the desktop apps as finished as REV’s hardware client or Phoenix Tuner. I understand that current FRC controllers can use the CAN bus or a simple PWM from the RIO to actually capture data needed to control the motor, and that any configuration is programmed into the controller beforehand and generally not changed during a match. All of that essentially to create a truth table in code that looks out the data stream coming in and determines high/low outputs to the pins on the driver IC.

On the actual “usability of the hardware” side, seems wago style lever connectors are becoming more popular in FRC in general, so I intended to design this board with those connectors for main power in from the PDP and out to the motor, and for CAN/PWM. I wish to have the final package similar in fit/function to the SPARK MAX. In fact a NEO/NEO550 will probably be the motor I end up using to test the board, so the encoder port will match NEO standard pin outs.

Other than reading through the data sheets for the both the mentioned IC above the the RPI-Pico, there isn’t much yet on paper, and most definitely nothing in stone. If it’s not obvious, the reason I’m even starting this thread so early on in the design process is that I wish for this project to be somewhat open source. I am not designing this controller for use on an FRC bot, or as anything I’d go to FIRST with the goal of developing a product for use in competition. I am designing this controller and documenting the process as a general resource to anyone who even thinks of doing this, especially because it’s technically totally possible for a team to develop their own controller, seeing as how PCB design software is included in the KOP now a days. (Maybe REV or CTRE would like to provide insight from their own products?)

So, just in case you forgot what my initial question was. What am I missing from my general understanding of FRC style controllers, and what features would you like to see in a controller that’s missing from currently available controllers?

5 Likes
2

What kind of drivetrain? IF a KoP…you can run a NEO/Sparkmax combo with great results. Swerve…same thing…I would look at the Swerve Max setup. It is an all inclusive kit (minus the motors…can use 2 NEOs per corner or NEO and 550). Motors are inexpensive.

Since we were introduced to wago’s…we solely use them.

REVs stuff is good for what you need…as to Phoenix…I will let others address that.

The other things you need to consider is the availability of stuff. Falcons are hard to get (can be found used though)…the Kraken is still not officially out to us mere mortals. NEOs are available…SparkMax as well…though both can be on back order at different times. And then there is the Vortex/Flex…that are not out as well.

Cost is always a concern for us. We don’t have the largest budget.

Coding and things…I will leave to the pros on this as well.

Wheels and “tires”…make sure you have sticky ones! And a lot of back ups as well.

3

I see confusion…and it is me. I misread the thought.

2 Likes
4

A couple thoughts from someone with absolutely no qualifications:

  • Why use an RPi Pico or other off-the-shelf dev board? It’s not very hard to make your own if you’re already doing SMD assembly and design, and tight hardware integration matters a lot. Also lets you add features like TVS diodes that generally aren’t included in dev boards.
  • That motor driver is only rated for 8 A continuous, which is pretty much nothing in FRC.
  • Why go with a motor driver with integrated FETs? It’ll probably be simpler to do discrete transistors and thermals/current capacity will be better, and doing motor control in MCU firmware will be cheaper/more configurable than doing it in silicon on that drier chip.
  • CAN as a protocol needs state, so a truth table won’t work. Even without, I think it would pretty quickly balloon in size. I would definitely give a lot more thought to software, and maybe look towards a full RTOS with scheduling etc.

This is an interesting project, I look forward to seeing more!

(by the way, I wouldn’t use the Altium included in the KoP. KiCad is significantly more accessable and is fairly comparable)

6 Likes
5

While I believe it would be better for total size of package to integrate the controller into one PCB, and probably best from a cost and production standpoint, I would rather only kill one half of the project accidentally and be able to replace it than kill an entire single unit. Maybe in a future revision, but I’m keeping both separate at first.

Yeah, I was waiting to hear someone say that. I believe you’re right. When I was originally reading through the paper, I understood that 8 amp number to be the output per phase, not total. Either way, you’re right, that’s probably way too low for an FRC application.

Pointing that out plus what you said in the last list item is making me reconsider the IC. Looking at some other options, I’m beginning to realize external FETs is the better strategy, and that I need just a gate driver IC.

You’re right, and I used the term incorrectly/out of context. I understand that translating CAN frames into data which in turn can then be evaluated to decide the state of pins is more involved than a truth table. I was, for half a second, considering an RPi-Zero over the Pico. That consideration may come back if I find I need a controller more readily able to process CAN/[insert comms protocol here]

6

How Brushless DC Motor Works? BLDC and ESC Explained is a pretty good introduction. Spend a lot of time searching and picking parts, reading data sheets, and understanding everything. A lot of these parts include reference designs, and have reference firmware available. Iterate things on paper until you are comfortable with everything, then compare to the guts of some of the current offerings.

You should probably try for a controller that drives the gates of all six external FETs and is designed for brushless motor control. Consider what kinds of sensing you will use, although your motor choice may dictate what you have available. FRC CAN has a safety protocol you’ll want to adopt, unless you never intend to put this on a robot.

If you pick the right parts, a lot of things will be better/easier.

1 Like
7

Better supply chain and cheaper :slight_smile: . The technical wants are much further down on my list at the moment.

If you pop a spark max open, you’ll actually find two circuit boards. The system is roughly divided between “high power” and “low power”.

This is a good design for a few reasons:

  1. Reduces the chances of electronics-killing current from ending up where you don’t want it
  2. Increased chance you might be able to repair a unit and return it to the field without swapping 100% of its guts.

It’s bad design for other reasons:

  1. The interconnect is a point of failure
  2. Assembly requires more steps (probably manual?) and therefore costs more

As a separate question, for development purposes, designing around a commonly-available dev board is a good way to get started. But unless you are purposefully trying to make something “hackable”, I’d flatten the PCB design down to just the layers you think your users might care about - not what’s easy for development.

jlbpcb.com, my beloved.

But, that being said… note that anything that’s in the e-stop signal chain from button to actuator has to be FIRST tested/approved. Something a team custom builds is unlikely to ever fit this. A huge blocker to adoption on any project like this is getting HQ to make it legal.

1 Like
8

That’s one of the articles I found a few weeks back when this project was still just “How to wire an ESC to an arduino so I can have a battle bot.” The past few weeks have been learning how brushless motors are controlled, and I know I’ll be going back to those basics a lot during this process, so I thank you for pointing this out.

That being said, if anyone has some dead motor controllers they haven’t thrown out yet, I’d love to hack-em apart with axe and take a look around the insides…

I’ll have to look into FRC CAN and it’s specifics, but I’ll keep that in mind for later down the line.

A lot of this will be on paper first, if not for nothing, I am still just a college student with a college-student’s self earned budget of not a lot - tax

9

It’s a good thing I’m not looking for FIRST’s approval. I am not a company, nor am I representing one. I am not looking to make a product that could ever be thought of as safe enough for FIRST’s safety theater. I am not trying to sell anything that one would choose over another COTS item. This project is falling strictly in the personal hobbies category… it just so happens that robotics in general finds itself in that category for me, FIRST is what I know best when it comes to robotics, and that only I could be responsible for the dangers that come with partaking in this hobby.

That being said, should I try to design to what I believe FIRST would want to see in a controller? It’s a nice idea, and I’ll definitely integrate at least some measurable amount of safety features… but it’s hard when the organization won’t transparently tell us what those safety requirements are and how they would prefer to see them implemented.

1 Like
10

As I was beginning to read through some of the layout recommendations for driver chips, it became apparent that keeping high-power and low-power separate was important. Moving those voltages to two different boards was an idea I had, and I may still if I have trouble laying both voltages on one board.

My first few boards probably won’t do everything I want them to do, and developing features as I make other ones work was my general strategy for development.

11

I’ve done a lot in this area, so I feel qualified to comment.

First of all, you will definitely need to separate the three primary components of your controller: the microcontroller (MCU), gate driver, and MOSFETs. Nothing integrated will get even close to the 12V 40A drive current that FRC expects. I recommend starting with the DRV8323SR, as it is very configurable over SPI to suit your needs. If you don’t care about FOC, something cheap like an EG2133 or DRV8300 can work just fine, you just need to spend more time tuning the gate drive series resistors. Those get hot, by the way, so use at least 0603 size, preferably 0805 if you can swing it.

As far as actually designing this goes, I highly recommend you look at all of Rick Hartley’s longform talks on YouTube about PCB design, specifically power and ground routing. This will take you about 8 hours and you will learn more than you ever have about PCB design in those 8 hours. I recommend screenshotting useful information like capacitor typical inductances or plane capacitances. Then, take a look at this TI guide on components used in high power motor drivers. It’s excellent and you should implement almost all of that manual into your PCB schematic/layout.

Once you check out those docs, look at the VESC schematics for ideas on how the general layout of the controller should look. I wouldn’t copy it wholesale - it tends to be kind of expensive, and it’s designed for higher voltage - but it’s really useful to know what your microcontroller kind of has to do. The Mini Cheetah controller schematics are also really simple, although the PCB layout leaves something to be desired. Still, it’s a good reference. I would not try to use an external dev board to control this. Maybe for the prototype that’s fine, but once you get into the final versions you’ll want to just design the MCU directly onto the board. I promise it is not that hard, just copy the reference design.

The most important question, after all of this, is how to get rid of heat. You should first calculate the switching losses in your MOSFETs, where the bulk of the heat will be generated. This app note from Rohm is succinct and covers the major players: conduction, switching, dead time, and gate charge. I recommend doing this in Excel so that you can compare multiple MOSFETs with a variety of switching frequencies between 15-40kHz. Then make an approximate simulation of your power stage, including parasitic inductances of the long power wires, so that you can see how much the board’s VCC swings given your bulk and high-frequency ceramic capacitances. This will also help you find the ripple current in your caps, which is important to make sure they don’t overheat and smoke. Here’s an example sim I did in LTSpice:

image
image1654×659 21.1 KB

You don’t have to do do any of the above stuff perfectly. I’ve seen some really grimy layouts work for motor controllers. But the more you know, the easier it will be to debug weird issues and maximize performance. Expect to rev this once or twice, and put test points on as many nets as you can to make sure that you can cut and bypass traces with wires if you need to. Your first attempt probably won’t work.

Finally, I recommend doing your design in KiCAD and using JLCPCB to make your board. KiCAD has a Production Toolkit extension someone made to generate files for JLCPCB assembly easily, and it comes with a ton of built in parts and packages to make getting started easy. I daily drive Altium at work, but it’s a pain to set up (to say nothing of other, even more developed EDA packages). Using KiCAD will let you move from a schematic/layout straight into a finished board as quickly as possible by leveraging cheap JLCPCB assembly. Placing a hundred components by hand gets boring really fast, especially if you mess up one of them and can’t figure out why your board doesn’t work. Expect to make maybe $100-200 to get a bunch of protoypes done through JLC, up to $500 if you use thicker copper (recommended after you finish your prototype) and want the hardware to support FOC. If you try to get your board made domestically, it will cost literally ten times as much.

Here’s a few pics and videos of a tiny, $7 BOM cost FRC motor controller I designed a few years ago: https://photos.app.goo.gl/L6RGpTNA5KZtW2M26. If you want the raw design files for it just let me know. I never did thorough testing on it, and the layout is probably pretty horrendous, but it does commutate and track hall encoder position just fine despite its shortcomings. It uses an RP2040 MCU, EG2133 gate driver, and MCP2515 SPI-to-CAN controller (which could be cut if I used a nicer MCU with CAN).

image
image940×1254 61 KB

Do note that there is a HUGE firmware effort involved with these things. Since working with Redux I’ve come to realize that getting the device to work is 10% of the effort, with the other 90% being getting it to talk to the RoboRIO intelligently. If you can steal VESC or Odrive firmware that would be ideal, but then you’re probably going to need a pricier MCU. On the plus side, it’ll save you a ton of dev time, and you can always downgrade the MCU later if you want to try writing the FW yourself.

Hope this helps. Feel free to send me your design for review as well.

13 Likes
12

I will say you’re gonna be looking for the 3.6 version as the latest open source version for the motor controllers. They stopped development on this and are focusing on the pro line. I have had 4 of the 3s and 4 pros. Their firmware is great but the calibration steps and documentation for the 3s could use some work. Especially for non o-drive motors.

1 Like
13

First, that driver chip has my interests for a non FRC project if I can’t find a COTs control system prolly gonna take a look at it.

Have you looked at SimpleFOC? It probably wouldn’t support this driver board (Drivers | Arduino-FOC) but I was looking at the DRC8316 because it seems like it should be supported and save me a ton of painful dev.

There’s also a handful of DRV chips that don’t have integrated FETs which is not something you’d want for FRC.

14

You’re not going to get more than servo power out of any chip with integrated FETs. 12V at 8A is a lot of an FTC servo, but it’s not much for any common FRC task like spinning intake rollers or rotating swerve pods. The minimum I would look for is about 30A, at which point a combo of DRV8300 + 2mohm FET would run under $2 total and perform reasonably well.

Nothing wrong with servos, mind you, but they’re just a hair underpowered for most FRC tasks.

I thought they stopped open sourcing hardware, but were still updating the main firmware repo here: GitHub - odriverobotics/ODrive: High performance motor control

15

Sorry development is the wrong word, the 3.6 controller itself is Not Recommended for New Designs (NRND). They also don’t plan to go back to that style of Controller anytime soon from what I can tell as the 3.6 page recommends people move to the S1.

1 Like
16

Yeah. That was a poorly built sentence.

You don’t want integrated fets for frc.

(I do for my non frc application, 30w motors at 24v isn’t a lot of current, and I’m power constrained…)

17

You will have two, steep learning curves to climb in order to produce a successful motor controller design. The first is learning enough about electronic design to make an effective design. The second is learning how to most effectively arrange the components and the traces on the circuit board to minimize unwanted effects such as ringing, oscillations and EMI effects. @asid61 gives a lot of good advice on some resources to study. You will also have to acquire test equipment capable of detecting the unwanted circuit operation and learn how to use them properly.

Some issues you may want to watch out for are the bootstrap capacitors discharging when running at low motor RPMs, EMI and ground-bounce issues, coupling from the power circuit into the control circuitry, shoot-through effects and oscillations/ringing in the gate signal causing excessive heating in the output devices.

This is an easy way to ensure that the large and fast switching power stage currents do not flow through the power or ground nets of the control circuitry and cause “ground bounce” issues. These can lead to catastrophic failures as a coworker who was a novice at PCB layout discovered. It is also possible that the “power board” is made with heavier copper to increase the current carrying capacity of the traces. Unfortunately, the heavier copper makes it difficult to to make the fine pitch pads necessary for the microcontroller.

18

Well, thank you for the resources. I began skimming some of these last night, lots of details, but nothing that can’t be worked through.

Go big or go home. Yeah, I realize that this is one of the bigger hurtles right at the start after I get the schematic made. From what I’m reading, some of this is an iterative process, but there’s general guidelines to follow to get started on the right path. The unwanted effects of ringing, oscillations, and EMI are going to be effects I keep in mind while designing, and I’ll follow advice and techniques to prevent them.

That’s pretty neat! I would like to look at the design files for reference. Looks like this design was able to drive both brushed and brushless motors? I wasn’t completely sure if I was going to be able to do that with any of the gate driver ICs I’ve come across. Did you have to use two different

… Heh, firmware is gonna be fun :upside_down_face:

I’m not a software guy, but thinking over my requirements, I don’t believe the structure is going to be that overly difficult. CAN communication and SPI with the gate driver IC I imagine are probably the hardest parts (and without looking yet I am hoping there are just libraries I can use for that.) Actually controlling the gate driver IC doesn’t seem logically difficult, high and lows and a pwm signal.

Ohh… this looks neat. I’ll have to read up further on that, but I didn’t expect to be doing FOC until later down the line. It’ll wait for a future firmware revision, thankfully one not locked behind a paywall.

1 Like
19

The videos by Rick Hartley looked pretty comprehensive but didn’t seem to cover making “sheet busses” to reduce the loop inductance. You may have to hunt around to find resources describing how to do it. I was taught by a very talented guy who specialized in switching power supply design, pre-internet so I don’t have any specific resources to point you to.

It may be helpful to have someone with experience in “power electronics” to look over your PCB layout and to check the waveforms to ensure that the ringing and oscillations are not excessive. While you may be studying and “keeping it in mind”, there is no substitute for some experienced reviewing it. About a third of my work over the last 25 years has been fixing circuitry in products that had been released for production with ringing and/or oscillations causing problems.

1 Like
20

There was a little of that “sheet bus” stuff being talked about in one of the packets from TI I found, and I’ve made a note to look into that specific detail a little more. Funnily enough, one of the students who’s also on internship with me did his PCB project earlier in the summer, and I wanna say he used a technique similar for all the grounds on his PCB.

That being said, I wouldn’t be entering this project if I didn’t have local guidance available. Fun thing about taking an engineering degree, you meet a lot of people with a lot of experience. Currently I see myself at a stage of initial research where nothing is specific, and general guidance from the average knowledge pot that is the internet is my best tool. And I thank everyone who has pointed out resources to me so far, puts me a step ahead, which is a step more than where I was before. I have friends who can help me with troubleshooting/testing later down the line.

And for peace of mind, I tend to say things like “keeping it in mind”/“making a note” when in actuality I’m most likely simultaneously hitting the print button on a document talking about said thing to add to my research docs binder. I don’t want to sound like I’m brushing details away only to come back to them later as an obstacle. I apologize if my phrasing indicated otherwise.

1 Like