Hi, I’m new here. Core team suggested I use this driver DRI0041 for 12VDC motors with Quad encoders, but I’m struggling to find how to wire them. The wiring diagram provided motors without encoders. I don’t know how to code, or wire components, but with the help of AI & and an online coding lessons I have been able to control 2 servos on X & Y planes with an MPU6050 and Uno board using PID control with Kalman filtering, (also just added adjust set point with button and reset to true horizon with button) point now I need to move to controlling motors that I will use to make Linear actuators (I can design & machine, but I can’t electronic!!) But…even my AI buddy can’t help with this one or anywhere else I can think to look with Google. I’m too old for this learning curve (64, I’m trying though), so please help out if you have real support to offer, thanks in advance to all.
The wiring from the driver to the motor doesn’t change just because the motor has a quad encoder, so you can follow the diagram provided with the driver.
If you are using a motor with a quad encoder then presumably you want to measure the motor direction and speed, and possibly you want to adjust the motor direction and/or speed based on the results. So the start is getting the quad encoder input into the MCU. Are you still using the UNO to monitor the motor? If so, this library looks promising:
GitHub - zacsketches/Encoder: Arduino quadrature encoder library. Implements a simple to use, interrupt driven quadrature decoder for Arduino.
There are other examples, but you can probably ignore the ones that don’t use interrupts. You would need to count the pulses over a time period to get speed, so it might not be suitable for fine control, but that’s a limitation of the Arduino clock speed, compared to newer MCUs. Once you know the speed and direction and if you work out what you want to do with that data then you can adjust the driver settings in a similar manner to what you already have for the servos.
Thanks Jeff, much appreciated.
I understand you say the wiring is the same, but unfortunately, I don’t know anything about electronics, but if you and the kind lad at Core say this driver will work with encoders, it must be true. Like everything, I’ll work on it till I get it, but this one is frustrating to say the least, the clues are aplenty, I just don’t seem to be able to put it into anything I understand at this point. Using AI I can nut out the code, but wiring this driver has got me stumped!
The driver will work with the encoder because it has nothing to do with it. The driver drives the motor. The encoder measures the speed and direction. They are separate functions.
Use the driver and the UNO to get the motor working using manual adjustment for direction and speed. The driver documentation shows the wiring and the Arduino library has code examples. If the wiring for driving the motor is not clear then you can post details of the motor and someone will point out any differences between the driver documentation and the motor documentation.
When that is working you can figure how to use the encoder to detect the direction and speed, using the library I mentioned above. When you can detect the direction and speed you can figure out how to use that information with some UNO code to control the motor instead of the manual control.
AI will give the best answers when you are asking the right question 
Hello Jeff, thanks for the help and advice, much appreciated, I believe you did the best you thought you could, for that I’m grateful.
I worry about my children & grandchildren’s future; how will we deal with our fellow man in times to come. 
Thank you for the comment. What was the result when you wired the motor as per the diagram for the driver? What is the link for the motor you are using?
Hi Andrew,
Glad to hear your projects coming along nicely - especially with the help of some AI!
Jeff’s sent through some amzing links that should get you over the line but if you need some more help just post a followup and we can jump in and help!
Liam
It was a simple question, forget it. I’ll go to Jaycar, one of the guys there will have the answer. If anyone needs help with Fusion 360, CNC, machining or structural engineering let me know. I will ensure I understand your question and the type of solution you are looking for, and if I don’t know the answer, I will surely let you know.
Wiring, I asked about wiring, not libraries or advice on AI. Focus lads, focus is the key.
Hi Andrew
Just what do you want to know. You have already been told the encoder wires have nothing to do with running the motor and until you have a use for them ignore.
Or do you want a blow by blow on the techniques of holding a pair of wire strippers and stripping the wire. I think following the wiring diagram and getting the motor(s) to rotate would be a good start.
You seem to have plenty of practical expertise so what is hard about connecting a couple of wires. You have been asked for motor details but so far nothing so we don’t even know the colours of the wires.
Yes and it was simply answered at the start of Jeff’s first reply.
Cheers Bob
Is it possible that the motors you have are not “12VDC motors with Quad encoders” but are actually BLDC motors? If so then that would explain the difficulty you have in following the wiring diagram for the driver you are using, because that driver is designed for DC motors, not BLDC motors.
Hi Jeff
I haven’t had much to do with them but don’t BLDC motors have just 3 wires. Or you could have BLDC motors with an encoder. Exact clarification re the motor would help.
Cheers Bob
Firstly, my public apology to Jeff, you must get a nutter every now and then, I’m declaring myself as one, sorry, and thanks for your help, I believe the forum appreciates it and so do I.
This is only the second time I have used a forum.
I have attached 3 screen shots for reference.
08.28.03 = Pins on motor encoder
08.32.02 = Image of wired plug to motor
08.34.13 = Image of Driver wiring diagram
Referring to the wiring diagram, I believe that in the set up shown, the motor is controlled by the code and only the code (apart from applied V to the motor) and the motor does not feed back data to the board.
In my application, the motor will be controlled by a gyroscope & accelerometer (MPU6050). There will need to be feed back from the motor so PID control and filtering can be implemented in the code. The code has a setpoint. The setpoint is adjustable (calculations need to be done to determine the control surface 0.degree of movement from motor speed, through reduction gearing, through trapezoidal lead screw & and anchor points)
Guys, the code is no problem, don’t worry about that, and I have a very basic understanding of how everything works. My issue is the wiring, this I am not sure about & I know that whatever pins on the board I use, need to be declared…
Referring to images .03 & .02 I believe the following is true:
Motor + = RED (+12V) (Plugs into supply from driver)?
Encoder GND = BLACK (Goes to GND on Uno)?
Encoder A Phase = YELLOW (Goes to Digital Pin on Uno (Input))?
Encoder B Phase = GREEN ( Goes to Digital Pin on Uno (Input))?
Encoder + 3.3V / 5.0V = BLUE (Goes to 3.3 or 5.0v on Uno)?
Motor - = WHITE (-12V) (Plugs into supply from driver)?
Then there must be 2 x PWM pins (Outputs) out to the driver?
Is this close to being true? I don’t physically have the motors or driver yet, they should arrive tomorrow.
The following is the basic code I was able to generate using a very little coding knowledge, and what I’m calling an “AI interrogation plan”. Surprisingly it works extremely well (the interrogation plan & the code) and is very stable, it wasn’t to start with. Since then I have added Kalman filtering and a bunch of things like change set point together by x, return to set point 0, change set point independently etc. etc.
I started with servos because they were easy to figure out the wiring and that was all I needed to ensure the code worked in real life.
#include <Wire.h>
#include <MPU6050.h>
#include <Servo.h>
MPU6050 mpu;
Servo servo1; // First trim tab
Servo servo2; // Second trim tab
// PID parameters
float setPoint = 0; // Assume level is 0
float pitch, roll;
float errorPitch, errorRoll;
float integralPitch = 0, integralRoll = 0;
float derivativePitch, derivativeRoll;
float lastErrorPitch = 0, lastErrorRoll = 0;
float outputPitch, outputRoll;
// PID constants
float Kp = 1, Ki = 0, Kd = 0;
// Complementary filter constants
const float alpha = 0.96;
float accPitch, accRoll, gyroPitchRate, gyroRollRate;
unsigned long lastTime = 0;
float dt;
void setup() {
Wire.begin();
Serial.begin(115200);
mpu.initialize();
if (!mpu.testConnection()) {
Serial.println(“MPU6050 connection failed”);
while (1);
}
servo1.attach(9); // Attach the servos to the appropriate pins
servo2.attach(10);
// Initialize the servos to the neutral position
servo1.write(90);
servo2.write(90);
// Prepare the MPU6050
mpu.setFullScaleAccelRange(0x00); // This corresponds to MPU6050_ACCEL_FS_2 from the error message
mpu.setFullScaleGyroRange(0x00); // This corresponds to MPU6050_GYRO_FS_250 from the error message
lastTime = millis();
}
void loop() {
// Read the raw data from the MPU6050
int16_t ax, ay, az;
int16_t gx, gy, gz;
mpu.getMotion6(&ax, &ay, &az, &gx, &gy, &gz);
// Calculate elapsed time
unsigned long currentTime = millis();
dt = (currentTime - lastTime) / 1000.0; // convert to seconds
lastTime = currentTime;
// Calculate the pitch and roll from the raw sensor data
accPitch = atan2(ay, az) * 180.0 / M_PI;
accRoll = atan2(-ax, az) * 180.0 / M_PI;
// Gyroscope rates in degrees per second
gyroPitchRate = gx / 131.0;
gyroRollRate = gy / 131.0;
// Integrate the gyroscope data
pitch += gyroPitchRate * dt;
roll += gyroRollRate * dt;
// Apply the complementary filter
pitch = pitch * alpha + accPitch * (1 - alpha);
roll = roll * alpha + accRoll * (1 - alpha);
// Compute the PID values
errorPitch = setPoint - pitch;
integralPitch += errorPitch * dt;
derivativePitch = (errorPitch - lastErrorPitch) / dt;
outputPitch = Kp * errorPitch + Ki * integralPitch + Kd * derivativePitch;
errorRoll = setPoint - roll;
integralRoll += errorRoll * dt;
derivativeRoll = (errorRoll - lastErrorRoll) / dt;
outputRoll = Kp * errorRoll + Ki * integralRoll + Kd * derivativeRoll;
// Update the servo positions
servo1.write(constrain(90 + outputPitch, 0, 180));
servo2.write(constrain(90 + outputRoll, 0, 180));
lastErrorPitch = errorPitch;
lastErrorRoll = errorRoll;
// I might need to adjust this delay to match the speed of my control loop
delay(20);
}
A DC motor driver does not include any facility for handling encoder data from the motor to the board.
If the motor is a DC motor then the wiring to use the decoder will be described in the reference for the library you use, such as the one I mentioned. It will be different for whichever linrary you choose to use, although adjustments could likely be made in the code to suit whatever wiring is convenient. It has nothing to do with the DC driver.
It is possible that your motor may be a BLDC motor, not a DC motor, although the connections don’t really match. If that is so then a DC driver will not work - you would need a BLDC 3-phase driver.
This is a typical BLDC driver:
SparkFun Brushless Motor Driver - 3-Phase (TMC6300) | ROB-21867 | Core Electronics Australia (core-electronics.com.au)
There is wiring details in the documentation for that driver which should match your motor (I haven’t looked in detail) so if you look at the documentation for the driver you may be able to confirm that it will connect to your motor. That will confirm that it is a BLDC motor. You could also post a link to your motor and someone on the forum could confirm exactly what driver it needs.
Hi Andrew
The following refers to the connections on the motor.
Motor supply is a separate pair of terminal points. Is what the name implies “Motor supply” This pin you are referring to (part of a 6 pin group) is the actual motor Positive connection. This connects to one of the other two 2 pin terminal points for "Motor 1 (or 2, or “A” or “B”) Positive.
Ignore the next 4 pins for the moment.
Pin 6 is the motor negative connection. This connects to the other pin, "Motor 1 (or 2, or “A” or “B”) Negative on the same block as above.
This board has 2 completely separate motor drivers with a common supply shown in the wiring sketch as a bench top unit.
The other connections shown are for PWM and direction control and can be wired as shown.
The driver logic power and ground are the red and green wires on the sketch going to the red connector on the UNO.
Yes, one for each motor driver. There are 3 control signals for each driver on that board. Forward, Reverse and PWM (speed). They must be kept in their respective groups.
I would suggest ignoring the encoder wiring until you get the motors working properly.
The encoder is entirely separate. They will eventually be connected to digital inputs on the INO (or whatever)for decoding. The provision of input voltage to the encoder. suggests pull ups fitted to the encoder module so no pull ups should be required externally. The encoder will provide a quadrature switching to ground with the A and B phase 90º apart so that decoding will provide direction, relative position and speed. Whichever is required.
Yes to all. As suggested above external (or internal) pull ups should not be needed on inputs. This can be stated with more certainty if and when more detail is forthcoming re motor and encoder. The switches should be magnetic or optical but if not some debouncing will be required. When it is known exactly what type of switching is employed and what is the type of interface between encoder switch and UNO some sort of suggestions can be made.
Some time ago I did some experimenting re this bounce. Results here if you are interested.
Encoder Module with button (CE09436)
Rotary Encoder de-bounce with Nand gates
If course if you have no use for the encoder then you can completely ignore all of this.
Cheers Bob
Thanks Guys, I knew I forgot something…this is the actual motor (not delivered yet)
Specification
- Rated Voltage: 12V
- Gear Reduction Ratio: 34:1
- No-Load Speed: 350 rpm@12v
- No-Load Current: 0.23A
- Maximum efficiency point parameters: 2.0kg.cm/285rpm/5.0W/0.65A
- Maximum power point parameters: 5.8kg.cm/180rpm/9.0W/1.65A
- Stall current: 5.5A
- Stall torque: 12kg.cm
- Hall Feedback Resolution: 374
- Weight: 98g
The SKU is FIT0493.
If course if you have no use for the encoder then you can completely ignore all of this.
Cheers Bob
Yes, I need the encoder. I’ll explain what I think I understand, let me know if I’m wrong.
A servo uses an inbuilt potentiometer. (& Im just using simple terms) to let the board know where it is in its arc of swing.
An encoder (in my case a hall effect sensor) fitted to a motor does the same thing, it can feed back to the board its speed, direction and number of “steps or pulses” X amount of pulses = 1 revolution. Using the correct library should make all this work. I just dont fully understand the wiring yet, but I’m much closer now.
I will be trying this way first
#include <MsTimer2.h> //Internal timer2
#include <PinChangeInt.h> //This library file can make all pins on the board as external interrupts. Define three-axis acceleration, three-axis gyroscope variables
#include <MPU6050.h> //MPU6050 Library
#include <Wire.h> //IIC communication library
MPU6050 mpu6050; // Instantiate an MPU6050 object; name mpu6050
int16_t ax, ay, az, gx, gy, gz; //Define three-axis acceleration, three-axis gyroscope variables
Cheers again.
The problem with this way is that if you run into a problem it will be very difficult to find which part of the process is causing the issue. There is a simpler example here:
That would be a good starting point to ensure everything is working before adding the complication of the MPU6050. Note that this example does not use a library - this complicates the code somewhat, but has the advantage that the process is clearly set out in the code. The library may allow operation at higher rates, but whether or not that matters that depends on your application.
That example uses pins 2 and 3 of the Arduino. When you adjust to different examples the CLK and DATA pins on the Arduino might change, and if you use interrupts which one is CLK and which one is DATA might become important - it will depend on the code. Also note that your even though the encoder power appears to be 3.3V, the output should drive the input pins of a 5V Arduino without a problem.
Hi Andrew
That is better. But even with the SKU number and looking up DFrobot site does not give any details about exactly what the encoder interface is. The mention of a hall output suggests magnetic switching and probably a schmidt trigger hall switch. In that case no pull ups or debounce should be needed.
I think you will find the motor encoder will provide an A phase and B phase switched to ground the A phase leading the B phase by 90º when the motor turns clockwise and the B phase leading when turning CCW. It will be up to you to decode this and do something with it. Unlike a Servo which uses a Pot to provide absolute position, positional output will be relative to the position at switch on so to be of any use the motor would have to be driven to a zero reference point to start any operation. But this is probably a bit downstream.
Cheers Bob
EDIT
“encoder will provide an A phase and B phase switched to ground”
This could be a positive going pulse. In the absence of detailed interface information I have assumed “switch to ground” as this is the “normal” isolated encoder operation. This does not have to be so as it could just as well switch to VCC. Everything else applies except the pulse sense is reversed.
Hi Andrew,
Circling back to your original problem of wiring them.
(Bob and Jeff have some other amazing resources worth exploring once you have your motors working).
This diagram is correct, using the motor- and motor+ wires from the cable included are the red and black wires coming from each motor in the diagram.
The other 4 wires make up the encoder connections that you’ll have to make to the Uno - Jeff’s and Bobs resources will be helpful here.
Let us know if you have any other questions!
Liam
Thanks Jeff & Robert. I have now got the wiring sorted out and I’m incrementally working my way through developing the code, learning how to control the motors. I can’t write code, but I have some help, so it’s a tedious progress, but, surprisingly how much I’m picking up by doing it this way. I’ll post some results as soon as I have something interesting!
Cheers!!
Hi Andrew,
Glad to hear you have some good support for the code. It can be a very gruelling self driven process but you will look back and see how far you have come in no time.
Looking forward to what you have to share next!
