Index
- BMSBattery S series
- BMSBattery S06S
- S06ST (torque sensor version)
- S06S-BL (Bluetooth version)
- PWM signals
- Phase B current signal
- Throttle
- BMSBattery S06SC
- BMSBattery S12S
- BMSBattery bottle battery controller
- LCD control panel
- Kunteng mobile app
- Bluetooh
- How to open the controller and solder the programming header
- Hardware mods
- Other controllers
- BMSBattery S06P
- Kunteng 18 mosfets motor controller
- Lishui motor controllers
- JinHui motor controllers
- GreenEBikeKit
- Torque speed
- Motor control scheme of S06S controller
- BLDC 6 steps
- PWM schemes
- So, Which PWM Technique is Best? (Part 1)
- So, Which PWM Technique is Best? (Part 2)
- So, Which PWM Technique is Best? (Part 3)
- So, Which PWM Technique is Best? (Part 4)
- So, Which PWM Technique is Best? (Part 5)
- So, Which PWM Technique is Best? (Part 6)
- So, Which PWM Technique is Best? (Part 7)
- PWM control and Dead Time Insertion
- Low inductance motors
- Throttle Control Modes
- Phase angle FOC
- PWM frequency VS motor eRPM
- Sinusoidal Control of BLDCM with Hall Sensors Based
- Self-Learn Hall Sensor Calibration Mode
- STM8S105 Alternatives
- PID algorithm - negative output values
- Regeneration
- FOC
Datasheets and application notes
- STM8S105C6T6
- Endless-sphere.com forum messages
- 2017.04.25 - Initial forum message
- 2017.05.08 - First flash and debug on a dev board
- 2017.05.18 - First code flashing and running
- 2017.05.20 - more new information
- 2017.08.23 - SxxP versus SxxS versus LSW-675
- 2017.09.01 - Trying to figure out an algorithm to automatically adjust ui8_position_correction_value
- 2017.09.02 - How to do FOC on the BMSBattery S06S/Kunteng STM8 motor controllers
- 2017.09.03 - more ideas about zero crossing for FOC
- 2017.09.05 - measuring IQ current and manually adjusting position_correction_value
- 2017.09.15 - our OpenSource firmware efficiency compared to Lishui 12 FET FOC
- 2017.09.19 - measuring motor current
- 2017.10.23 - FOC and no FOC comparison
- 2018.01.10 - How to measure FOC_READ_ID_CURRENT_ANGLE_ADJUST
- 2018.02.20 - Reading motor phase current from the DC link current (shunt)
PID algorithm - negative output values
http://forum.arduino.cc/index.php?topic=297543.0PID: should negative error [1] decrease PWM-value or [2] reverse motor direction
Feb 03, 2015, 09:02 pm
The procedure that drives my motors accepts positive and negative inputs [-100, +100].
The sign determines the direction of the motor, the number the speed.
if (motorSpeed >= 0)
{
digitalWrite(m1In1, HIGH); // Forward
digitalWrite(m1In2, LOW);
}
else
{
digitalWrite(m1In1, LOW); // Backward
digitalWrite(m1In2, HIGH);
I use the number to calculate the desired time between the pulses of the wheel encoder (=set point).
The error is the difference between set point and the encoder reading (m1Pulse)
error = (long)desiredPulse -(long)m1Pulse;
My PID-code is as follows:
Kp = 50;
Ki = 0;
Kd = 0;
m1Pwm = Kp * error / 100; // m1Pwm is Pwm value of motor #1
m1Pwm += Ki * sumError / 100;
m1Pwm += Kd * (error - lastError) / 100;
lastError = error; // set the last and sumerrors for next loop iteration
sumError += error;
if (m1Pwm > 255) { m1Pwm = 255;}
if (m1Pwm <= 0) {m1Pwm 0;}
analogWrite(m1D2,m1Pwm);
The error signal can be positive or negative.
If the error is positive it's the speed goes step by step towards set point => ok
But if the error is negative the Pwm-signal equals 0 => no smooth operation
Question: what to do with negative error values?
1)
Decrease pwm-value gradually (if yes, how?)
I tried the following (no satisfactory results)
if (m1Pwm > 127) { m1Pwm = 127;}
if (m1Pwm < -127) {m1Pwm = -127;}
m1Pwm = 127 - m1Pwm;
analogWrite(m1D2,abs(m1Pwm));
2)
Reverse motor direction and apply the abs value of the error as Pwm-value (breaking on the motor)?
MarkT
•
•
• Brattain Member
• Posts: 26,758
• Karma: 1305 [add]
• Arduino rocks
Re: PID: should negative error [1] decrease PWM-value or [2] reverse motor direction#1
Feb 03, 2015, 11:47 pm
The output of the PID is a signed value that should be passed to a routine that can drive
the motor either direction according to the sign.
You mention using the number to set the desired time between encoder pulses - that's
wrong, you want the input number to set the frequency of pulses, thats proportional to speed.[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]
kegde
• Guest
Re: PID: should negative error [1] decrease PWM-value or [2] reverse motor direction#2
Feb 04, 2015, 09:44 am
I will adapt the code to work with pulse frequency, that's a good point, thnx.
I still don't understand the conversion form the signed PID-value to the motor drive comand. In see it this way (but I am not sure if that's ok):
1)
the direction stays the same;
positive PID => increase Pwm
negative PID => decrease Pwm
Pseudo implementation:
Pwm = Pwm + PID // adjust value
If Pwm > 255 Then Pwm = 255
If Pwm <=0 Then Pwm = 0;
I experimented with this implementation => bad and jitttery results (maybe because I worked withe pulse time in stead of frequency)
2)
I also experimented with:
Pwm = PID
If Pwm > 255 Then Pwm = 255
If Pwm <=0 Then Pwm = 0;
Better results, but great spread @ Pwm-values (if error is negave => Pwm = 0 => next Pwm value verry high +250).
3)
And I tried:
If error changes sign Then Reverse Motor direction
Pwm = abs (PID) [0-255]
Poor, jittery results.
Is option 1) indeed the way to go?
Or should I go for option 2) or 3)?
Or something else?
MarkT
•
•
• Brattain Member
• Posts: 26,758
• Karma: 1305 [add]
• Arduino rocks
Re: PID: should negative error [1] decrease PWM-value or [2] reverse motor direction#3
Feb 04, 2015, 02:02 pm
Last Edit: Feb 04, 2015, 02:03 pm by MarkT
In general 3) is the way to go. You must have fast-decay mode (synchronous rectification) on
the H-bridge for servo drive like this, otherwise the system is highly non-linear as a whole.
The jitter you may be seeing is the PID actually working. Such jitter can arise
from noise in the sensing system or in having the gain too high (oscillation is
also caused by this).
Your input to the PID algorithm must be a speed, not a pulse-time, since that's the
reciprocal of speed (again that's a highly non-linear system, avoid like the plague).