hi,
is for the BrickPi3 C++ API a PID regulation available?
It should run locally on either BrickPi3 ARM cores because of regulation speed and accuracy, not to be delayed by SPI data transmission bottlenecks when controlling + regulating multiple motors on multiple BrickPi3 HATs independently and simultaneously in multiple independent threads:
a) appoach target position, then switch off (coast)
b) appoach target position, then brake (by brake power)
c) appoach target position + then hold position against external force perpetually (until cancelled by user)
d) cancel a running PID regulation thread immaturely
kP, kI, kD parameters and setpoints (encoder or sensor values) to be set arbitrarily by the user program
(that is actually what was available for NXC and leJOS)
set_motor_position will run a motor to the specified position (managed by the BrickPi3 firmware). set_motor_dps will run a motor at a specific (regulated) speed, specified in Degrees Per Second (managed by the BrickPi3 firmware). set_motor_limits can limit the motor PWM power (which would limit torque and maximum speed), and/or motor speed in DPS (for position control).
You can cancel the motor control by using set_motor_power and setting the power to e.g. MOTOR_FLOAT.
You could theoretically set the P and D konstants, but the drivers don’t support itnow supported as of August 31st 2017. They are tuned to work under most circumstances, and work well with the NXT motor and both EV3 motors.
Since “approach target position” is relative (very dependent on the use-case), the best way to implement coast/brake on reaching the target would be for the user program to monitor the encoder, and then float/brake the motor when it’s close enough. Until canceled, set_motor_position will continually try to get the motor to reach the target (active hold, sort of like an RC servo).
thank you for your clarification!
so IIURC, set_motor_position will always keep active to finally an active hold and never switches off by itself.
About the setpoints of the motor PID regulators:
do I understand correctly, that they always are related to the proprietary rotation encoder values (current vs. targeted) and that they cannot be changed to other setpoints as a targeted value, e.g. a distance value (of an US sensor, to track a moving object), a brightness value (of a light sensor, for a line follower), the rotation degree (of a gyro sensor, for balancing), or a heading (of a compass or an IMU, for navigation and routing purposes) ?
If you want to control the motors based on something other than encoder value (current position vs. target position), you will need to implement the algorithm into the user code. There’s no way to implement all those scenarios into the firmware. The firmware gives the user program access to values, and allows the user program to run motors etc., but the user program needs to handle dealing with sensor values and telling the motors what to do.
thanks, I see.
I was curious about the PID regulator implementation on the ARM cores, because I was used to the Arduino PID_v1 regulator lib. In this case one was free to use either value sources, e.g. encoder values, or sensor values, or anything as a setpoint. The setpoint source just had to be declared when initializing the PID regulator from where it had to get his values from which then had to be regulated.