2020-02-26

2020-02-16 OrangeBot High Precision Controls


>>>Pi Wars 2020<<< 



1OrangeBot PID

Precision was identified early in the design of OrangeBot as the most important factor for the competitiveness platform. To achieve high precision, a PID controller is necessary.

1.1Development History

A first round of design proved that the motors were too week to steer, so the scope of the platform was reduced from four to two motors. Another round of design proved that it was impossible to build a worthy PID with the combination of motors and encoders, and the encoders have been replaced higher resolution optical encoders.
Still, the PID controller proved elusive. Multiple rounds of firmware redesign, and feature creep on both firmware and software were needed to finally elevate the controls to Pi-Wars grade. A gargantuan endeavour, that finally paid off.

1.2Hardware Specifications

OrangeBot is powered by two DC motors with encoders, with a passive steering pivot wheel.

Illustration 1: OrangeBot Undercarriage
Wheels:
  • 127 [mm]
  • High grip rubber
Motors:
  • 12 [V]
  • 5 [A]
  • 5.25:1 Reducer
  • 1140 [RPM]
Encoders:
  • Resolution: 300 [Pulse]
  • Quadrature: 4 [Count/Pulse]
Platform:
  • Top Speed: 40 [Km/h]
  • Encoder Resolution: 6300 [cnt/Turn]
  • Encoder Resolution: 63.33 [um/cnt]
  • Encoder Resolution: 15.79 [cnt/mm]

1.3Problems

Several problems were encountered during the design phase.
  • Supply chain problems resulted in motors with a faster reducer than originally planned
  • A mistake in the design where skidding torque was overlooked resulted in the platform being unable to turn in a four motor configuration. Design was reduced in scope to two master wheels a one pivot wheel
  • Due to inertia, the platform has the tendency to turn on itself when going forward and slowing down, making PWM controls unwieldy
  • Due to the high gain of the motors, the closed loop control is hard to stabilize. A command of 10% is needed to achieve 1[m/s] but low torque is achieved at 10% command.
The issues needed a lot of extra resources to tackle and solve, and by now have mostly been addressed.




Video 1: OrangeBot Cannot Turn

2PID Class

The PID is a self contained C++ class hosted inside the AT4809 20Mhz microcontroller, and is equipped with several features meant to improve the quality of the controls:
  • Proportional/Integral/Derivative gains
  • Two Slope Error gain: Gain is boosted for low errors, improving precision without causing too much instability at high errors.
  • Error Monitoring: error is passed to a low pass filter and reported to the user. Error gives a pulse on how hard a time the PID is having, and helps with debug.
  • Slew Rate Monitoring: slew rate of command is computed, filtered and reported to the user.
  • Cut Off Protection: If the command is saturated to 100% for too long, or if slew rate is too high for too long, the PID automatically cuts off. This protects against runaway instability, inversion of gain or disconnection of the encoder.
  • Integral Saturation: If the command is saturated, the accumulator is forbidden from increasing any more. This makes sure that there is less accumulator to discharge when the error gets under control.
Multiple instance of the class (four right now) runs concurrently
Link to PID S16 C++ Class


Illustration 2: PID S16 Architecture

2.1Command Slew Rate Limiter

An additional C++ Class implements a multi channel slew rate limiter between the target PWM the controls want to achieve and what is sent to the motors. This prevents ringing commands to be executed by the driver, preventing hardware failure.

2.2PWM Linearization

The motors will not develop torque when the input voltage is below a certain threshold. The motor drivers will struggle to give power when the PWM is too high. This gives a maximum command and a minimum command.
For the maximum command, solution is straightforward. The HAL for the motors should saturate every command above a threshold PWM to that threshold.
For the minimum command there are a number of strategies. The one that works best is increasing every non zero command by the minimum threshold. This conserves linearity of the motor response to the PWM, making the work of the PID controllers that much easier and has had a great effect on dynamic response.

Illustration 3: OrangeBot Motor PWM Correction

3PID Features

A number of strategies have been tried to no avail while trying to achieve high precision controls. Here a short list of what has worked/not worked

3.1Feed Forward

Adding a derivative to the PID reference should allow the PID to predict a fraction of the command when the reference changes, instead of leaving it all to the error gains. While promising, this makes no difference for single loop implementations as the reference is pretty much a constant from keyboard.
This term should make a difference for inner loops, but requires a wealth of additional resources. Like a MAC and adding a gain term to each and every PID gain message and in debug visualization. I'm going to revisit this term when I mover to an higher capacity 32b microcontroller for the motor PID controls.

3.2Three samples derivative

Since the platform had a problem with dynamic response, a different discrete derivative formula was developed to use three asymmetric samples instead of two symmetric samples. Coefficients are optimized for minimum error to decaying natural exponential functions.
While on paper this gives a slight advantage in discretization error, in practice it eats on CPU time more than the advantage in decreased error. This technique was abandoned in the final implementation of the PID class.

3.3Second Order Derivative

An attempt was made to add a KDD second order derivative term by increasing by one the error memory and using a three sample symmetric second order discrete derivative, in an attempt to use just one PID loop to control both position and speed reference at the same time.
It doesn't work. Even if the final solution has the equivalent of four gains, with this solution you lack independent control of fixed point position for position and speed terms and lose the ability to decouple speed command and PWM command.

3.4Two Slope Error Gain

This module apply a correction to the PID error, amplifying it when the error is low. This module is meant to make the PID more sensitive to small error while reduce ringing and strength of the response at high error, allowing to use overall lower and more stable PID gains.

4Control System Development and Calibration

The control system of our previous platform required a lot of effort to calibrate as parameters were hardwired inside the microcontrollers near the motors and required flashing with each change.
With OrangeBot we put a lot of effort in the development of debug and runtime calibration tools to make sure we could achieve the high standards we set for ourselves in terms of precision of the controls.

4.1Debug

A desktop application to simulate position and speed systems was built to test the class and behaviour in a controlled and easily probable environment.
Next stage of simulation is using the AT4809 simulator to explore the behaviour and assembly generated by the PID, to fix all artefacts due to discrete finite precision mathematics.

Illustration 4: AVR Simulator

4.2Runtime PID Configuration Web Page

A dedicated page on the remote controls web page hosted inside OrangeBot allows to monitor in real time Error and Slew Rate of the PID controllers and to change in runtime the PID gains using sliders. Parameters are loaded at start up from a configuration file, and can be saved, reset and loaded with dedicated buttons in runtime.

Illustration : PID Configuration Page
This system means that the PID calibration is done with a convenient UI. Indeed, it's satisfying to move the sliders and feel the motors trying harder to stay in position and feel and hear the ringing as the controls get more nervous with forward and backward corrections desperately trying to keep the error in check.


5Control System

The control system of the platform provides multiple modes of operation that are selected in runtime:
  • PWM: RPI can directly control the PWM of the motors. OrangeBot is inherently hard to control in this mode.
  • FAST SPEED: A speed PID close the loop on the encoder derivative. This is good at high speed, but high speed in case of OrangeBot means between 1 [m/s] and 10 [m/s]. Unworkable for the Pi Wars
  • SLOW SPEED: The RPI gives a speed target, but the control system actually integrates that target to generate an integral position reference and close the loop on the encoder position. This modes can display some dynamic artefacts, but can be incredibly precise. The Control System automatically select between the FAST and SLOW speed modes in runtime.
  • POS: The RPI gives a position target. PID closes the loop on the encoder position.
     Illustration 5: Control System

5.1PWM Controls

The PWM controller takes the reference directly from a SET_PWM message from the NODE.JS application through UART. The PWM is passed to the slew rate limiter class every 500[us] to protect the electronics from quick back to back direction inversions.
The platform is barely controllable in this control mode due to the inertia of the platform and the high gains of the motors. When slowing down, the mass behind the wheels tries to swerve the platform in one direction or the other.

5.2Fast Speed Controls

The fast speed is implemented by computing the derivative of the encoder count, a PID controller and a PWM slew rate limiter in series. Scan time for this control system is 500 [us].
This control system is expected to shine when the platform reaches high speed. At low speed, the control system can't achieve smooth transitions due to the high gain of the motors.

5.3Position Controls

The position control is implemented by feeding the encoder count directly to a PID controller and a PWM slew rate limiter in series. Scan time for this control system is 500 [us].
This controller does a good job in keeping the wheels in position against external disturbances, but has ringing and settling problems. With low gain, the control is too soft and the platform struggle to maintain attitude and position. With high gain, the platform needs about a second to settle and is somewhat vulnerable to ringing. Gains must be extremely low, with fixed point position in place 15, the maximum that the PID controller can give.

5.4Slow Speed Controls

This controller takes the speed reference from the NODE.JS application and integrates it into a reference position. the encoder position count and reference, are fed to a PID controller running at 2000 [us] scan time. The command from the position controller is fed to a PID along with the encoder count derivative to a second PID running at a faster scan time of 500 [us]. The reference from this second speed PID is fed to the PWM slew rate limiter that generates the command to the drivers.
Care has to be taken to change the sign of the speed command has to be inverted to conserve the sign of the gains compared to other control modes.
This control scheme is the only one that is able to maintain a precise position, thanks to the position controller while achieving a good dynamic response, thanks to the speed controller.
The controller has been tested with great results at a command of 1 encoder count per slow control system update.

6Motor Gain

The conversion between PWM and platform linear speed speed is decided by the driver-motor-wheel assembly.
The extremely high gain of OrangeBot motor assembly has proved a significant problem to overcome during development.
The motor of choice at a target speed of 20 [Km/h] could not be supplied in time, so there was a choice between two motors. 10 [Km/h] and 40 [Km/h]. My previous platform at 8 [Km/h] was too slow to keep up with my walking pace when going off road, so the choice was taken to err on the fast side.
Because of this, the burden was offloaded on the PID controllers inside the AT4809 microcontroller to fight back against instability and achieve high precision despite the unstable nature of the platform. Indeed, with PWM manual controls, the platform was unable to maintain attitude, swerving in acceleration and deceleration.




Video 2 : PWM Controls instability
It took a gargantuan effort to keep adding and adding to the PID controllers, try new features and mathematics, refining them, until they were strong enough to achieve high precision, while keeping dynamic response manageable and at the same time stay light enough that the 20MHz AVR CPU was still able to close the loop without losing ticks.
Hat this effort failed, only solution would have been to discard the motors and perform another scope reduction to install slower motors on OrangeBot. Thankfully, we were stubborn enough to try until the control system became operational to the performance we set to achieve for the PiWars.

7High Precision Controls

With the control system up and running, a test was conducted to drive the robot at a low speed of 1 [cnt] every 2[ms]. At a resolution of 63.33 [um/cnt] this translates to a speed of 1/2e-3*63.33e-6 = 31.66 [mm/s]. The test was conducted on battery and Wi-Fi with video streaming active.




Video : High Precision Controls

8Conclusions:

The high precision closed loop controls for OrangeBot were planned to be operational by the beginning of January, and instead took until half February to be brought to PiWars grade level.
The mistake in the design of the motors forced the development of a far more refined control system than was bargained for in the design.
Achieving high precision in the controls was a key design decision, so our team was willing to forego development of all other features until the controls where not only operational, but operational with the degree of precision required for the Pi-Wars.
With this task finally achieved, development of challenge specific features to boost final score can begin.
In order of priority:
  • Add servo support to the main motor board
  • Complete the construction of the main weapon and the turret. Install support for the control of the turret on the firmware and the remote control page.
  • Install hard point for the Joust Equipment for the Pi-Noon challenge. Install support for the Joust Shaker.
  • Install hard point for the Barrel Mover Attachment (powered be two spare DC motor channel) and install support for barrel mover operation on the remote control page and firmware.
  • Install SRF02 I2C ultrasound sensors to the Raspberry Pi. Install software support for them in the NODE.JS application.
  • Construct the autopilot with start/stop button for the Lava Palaver challenge

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)