Ather Motor Controller: The Firmware and FOC story

Published in

Ather Engineering

8 min readJan 24, 2023

Hari Vasudevan, Ashwin Rao, Anup Gandra, Anshuman Tripathi

As Tarun explained in his keynote speech on the recent Ather Community Day, the AutoHold™️ feature has been a long time coming to the 450X/ connected platform. India is terraneous and we knew that adding this feature can really help riders avoid the fatigue of holding the vehicle up (along with their pillion rider) at flyovers, signals or in traffic. But before working on the feature, we had to first figure out our motor controller.

Ather’s Motor Controller

Motors and motor controls have existed for a very long time. However as with everything engineering and electric vehicles , to truly appreciate the full complexity of a motor and controller, you first have to build it. The expectations set at the beginning of the motor controller project were challenging, we had to come up with a controller that would at least match the performance levels of our existing vehicle. These involved system level constraints, namely, comparable range, equivalent thermal performance, and a requirement from the Product team that the motor and controller do not make any unusual noises — the signature Wheee does not come easy.

In addition to this, when we started off on the design of the controller, we aimed to make the most of in-house technology. This involved all of the hardware design and layout and all of the firmware components. When we talk of motor control, it is easy to think of the design as mainly involving the design of field-oriented control and the applications built on this, for instance autohold, park-assist etc…. However, the complexity of the firmware infrastructure that supports this is often overlooked.Hence when talking about the motor controller I will address — firmware architecture, Field-Oriented Control (FOC), and the application layer.

Firmware Architecture

When we started, we knew that motor control involved fast, low-latency control loops, so the firmware would need to support these rates. Given the ballpark inductance values of our Permanent Magnet Synchronous Motors (PMSM), the time constant of the motor inductance would be in the range of 1 to 10 milliseconds. A good rule of thumb is for the FOC loop to run at 10x this rate, which for us could be anywhere between 1KHz to 10KHz.

Translating this into firmware specs, this implies that the FOC loop is the one the microcontroller needs to run at the highest priority. Furthermore, all critical measurements of currents, temperatures, and voltages need to be initiated from the loop, read out of peripherals, and then acted upon by the FOC control code to generate Pulse Width Modulation (PWM) values as output.

If the FOC was the only thing the microcontroller had to run, this would have been fine, almost easy. However, the microcontroller needs to deal with much more, firstly communication with the rest of the vehicle. The Ather 450X ride experience depends heavily on all the Electronic Control Units (ECU) communicating in a coordinated fashion. Secondly, the microcontroller has to run other features that make the 450X unique and are crucial to the performance, such as the Warp Mode, the Park Assist or the AutoHold. For all this, the motor controller uses an RTOS to manage task priorities and timing. A basic diagram of the firmware architecture is shown below. We will do a deep dive into memory management, RTOS selection, and configuration, as well as the Ather Software Development Kit (ASDK) in another blog post.

Firmware Architecture of Motor Controller

Lastly, given that we were building our stack from the bottom up, we were wary of creating dependencies on any particular chip family or platform. Thus, all our code is C99 compliant and directly compiled on GCC. This is particularly important in the case of motor controllers where there is often the need to perform fast complex operations.

For example, consider the square root operation or the power operation. C language offers the sqrt() and the pow() functions defined in math.h for these operations. However, most ECUs are not compliant with this across all datatypes. For instance, the power operation is often defined only for the “double” datatype for most platforms, and standard code generation tools in matlab don’t by default substitute this with “powf” for float datatypes, instead preferring to typecast “float” dataypes as “double” in the pow() function and hence slowing down execution. Making these exceptions and workarounds would result in our code being platform dependent, and hence for the most part, we have avoided or redefined these functions.

This section would be incomplete without talking about the infamous sqrt() function. Because of the complexity of the underlying math, even though available, this function is unusable for low-latency applications on most microcontroller platforms. Instead, most chip vendors provide platform-specific implementations that directly compute this result with assembly language operations, which yet again meant platform-dependence. However, for the sqrt() functions we redefined an alternate Newton-Raphson approach that replaces the MIPS (Million Instructions Per Second) intensive sqrt().

It was partially our platform-independence (alongside Sourcing and Hardware qualification speeds) that helped us tide over the semiconductor crunch of 2022.

Field-Oriented Control

Modern PMSMs do not use slip rings or other mechanical means of switching the current in motor windings. In fact, the stator of the motor (the part that does not move) contains the windings and the rotor (the part that spins) contains the magnets. The position of the rotor is critical for the control of the motor, and is often connected to a resolver or encoder. The control system that reads the encoder position and the currents in the statorcommands a voltage to drive the motor which is known as the Field-Oriented Controller (FOC). It is not the intent of this blog to describe how the stator magnetic field rotates and spins the rotor with it. A good introduction to this can be found in this excellent book by R. Krishnan. To illustrate some basic concepts, here are some animations by Mahmoud Riaz.

For other applications, the PMSM may be required to control just one parameter, i.e. say for example a pump where the PMSM has to maintain a steady speed irrespective of the load. For an automotive application, the PMSM is required to deliver necessary torque at any speed the user is at, while simultaneously:

Maximising voltage utilisation (i.e. trade off current for voltage to maximise efficiency)
Operate at currents around the Maximum Torque Per Ampere (MTPA) operating point below base speed, while above the base speed perform simultaneous flux weakening and torque control
Operate within current limits of the DC link, motor conductor coils and Controller Field Effect Transistors (FET)
Operate within the temperature and magnetic limits of the motor
Handle transitions from motoring to regenerating for full 4-quadrant operation

Not least of all, the need was to achieve all of this while ensuring that the range of the 450X stays true to the TrueRange we promise.

The three-phase PMSM

The 450X’s motor is a 3-phase PMSM and hence has 3-phase connections that are used to control its motion. By actuating each of these, we can obtain a desired torque output.

An illustration of how the three phases are controlled to produce a resultant rotating magnetic field is reproduced below(M.Riaz).

While it is physically intuitive to think of motor control as the result of currents flowing in the three phases, established literature on motor control simplifies this into control over two currents assumed to be present in a rotating reference frame. We will not delve into the details here, if interested, read this comprehensive book by Krishnan R.

Rather, here’s a brief description of the design on the basic DQ-control (Synchronous Reference Control) loop that underpins the functioning of the FOC. The DQ transformation is a combination of the Park and Clarke transformations that result in the 3-phase system being transformed into a 2-phase one in the rotating coordinate system. The control loop implementation is a basic state-space pole placement design, however, I will use it here to demonstrate our design methodology.

ABC to DQ reference frame transformation

Visual representation of the rotating coordinate frame

The DQ Control loop

The DQ control loop is the innermost control loop of the FOC, it is designed to maintain the D & Q currents appropriate to generate the required torque and as such is formulated from the dynamic equations of the system. The dynamic equations of a PMSM are as follows:

Here for simplicity we assume that all the back-emf terms that follow the first term on the right constitute disturbance input into the dynamic system and that as such the dynamic equations used to design the controllers can be expressed as follows.

Further, we can augment these equations with an integral state to design the PI controller for both the loops.

The Application Layer

The application layer is where much of the vehicle-level functionality of the motor controller comes in. A simplified diagram of the Application layer with its interface with the FOC is shown below. Throttle response, drive modes, and features such as Park Assist and AutoHold are implemented in this layer. To learn more about the 450X’s smart features, please keep an eye out for the next in this series on our motor controller.

Before we conclude this blog, here are videos ofwhat we tried during the development of the controller. To recall what Tarun said in his keynote at our Community Day event, our control of the entire Ather Stack allows us to experiment with the controller in fun ways. The following two videos have sounds played out of not the speaker but the motor! The Tom and Jerry theme is a favourite, however the other audio being played out are the various sounds from the Gen 2 UI.

Tom & Jerry Theme on Motor — Feb 2021

Gen 2 UI Theme Sounds from Motor — Feb 2021

First spin-up of the motor — Oct 2020

Initial Dyno Test for the motor controller — Oct 2020