Code and Wiring for DB1 Motor Control
Received the motors and installed them. They do mount differently than the original motors Bill identified. You'll need to order the 206 Series Pattern Adaptor (1206-0016-0001) to mount the motors. The two motors run at slightly different speeds. I talked to an engineer that has used DC motors in control systems, and he said that the same motors usually operate at different speeds with the same PWM input. He said you need to use the encoder inputs to adjust the motors to the desired velocity. I am now looking for example code on controlling DC motor speed using the encoder inputs.
here is a link to a sparkfun video on using encoder input to control motors. There is a link in the youtube video to the code used on github
The video and code provided a good example of controlling the motors with the encoder. I also found some examples of controlling speed from the encoder input.
As I was going through the code I remembered that Bill's design has one ATMega328 for each motor controller card and each motor encoder input only goes to the corresponding ATMega328. There is no way for the Motor Controller to compare L/R encoder inputs and adjust the PWM signals. Channel B of the motors do go through the Motor Controller to the MEGA2560. I guess the 2560 will be responsible for comparing and adjusting the command back to the motor controller. I think I may have to wait until Bill dumps some code. I wonder why Bill didn't use a single ATMega328 to control both motors. Seems like it would have been easier.
Yes I agree. I remember writing something about this when @Dronebot-workshop submitted some code a way back. I thought that as it stood, the design for the the motor controller meant that the encoder logic would have to be done at a higher level, and that this did not necessarily make sense.
Well I've found the spiel I wrote back then and not knowing how to link to it I give it again - 🙂
I have the following thoughts on the motor control program, and indeed the DB1 design as thus far envisioned. So I emphasise, just my thoughts that may we be quite worthless especially as I may have lost the plot as to what the current design of DB1 is. (I have been following along, but it has been and extended process and memory may be lacking and I don't have time to revisit all the DB1 articles)
Where I am coming from is how I would think the commands from the 'thinking computer' that instructs on the robots movements would be issued. Something in its algorithms will trigger the issuing of a move command. To illustrate I give the example that a move in a straight line command is issued. Maybe this will be followed by a turn left command as the robots sensors indicate the end of a corridor is reached (whatever).
There are many ways to instruct the robot to move but it seems currently the design means the robots motors move by the 'thinking computer' instructing a microprocessor over i2c to to issue a command via both a PMW and a direction signal. It would appear to do this for 2 motors via 2 independent microcontrollers.
One thing we know about driving motors to send the robot in a straight line, even if both are given an identical PMW signal, is that they often don't drive the robot equally. So we monitor the encoders to check the rotation of each motor and through a PID mechanism the PMW sent to the motors is adjusted. We also know that during a turn manoeuvre where one motor is expected to both turn at a different rate and also direction, an encoder PID would not be wanted, though we may need a bearing PID to help ensure we achieved, say, a 90 degree turn.
So, where best to do the PID control? It would appear to be for the thinking computer. In this case we would require a continual stream of motor turn commands to vary the PMW sent to a motor at any one time. We would also need a continued stream of encoder feedback to be fed into the thinking layer. In this scenario it seems to indicate that the encoder connection is best connected directly to the thinking layer and not to the motor control microprocessor.
The PID control could also be done at the motor control level. This would indicate that perhaps a different command is sent to the microprocessor, something like 'go straight' or 'turn 90 degrees' (or 10 degrees etc). However in this case the microprocessor would really need to control both motors and receive the feedback from both motor controllers. The motor control program would need to recognise that 'go straight' meant the PMW PID was used and that 'turn 90 degrees' meant the compass bearing PID was used.
I think, therefore, before proper consideration of the motor control programming is given, just how the thinking computer will issue commands, and what commands they will be, should be specified.
So I'm with you on wondering about the DB1 design in relation to the motor control and encoder feedback . I don't suppose Bill is ready to chip in on his DB1 design yet, but having just one microprocessor to control the 2 motor controller boards would seen to remove some complications.
Great response. I wish Bill would have been a bit more committed to working on DB1 (except where dealing with family/heath issues), or at least if a group of individuals on the forum would work together and move the project forward. The way I see the current design working is:
1. Move command issued by the MEGA2560 to the Motor Controller card via I2C bus
2. Motor Controller sends the appropriate signal to the MD10Cs
3. Motor encoder signals A & B sent back to the Motor Controller
4. Motor encode signal A sent from the Motor Controller Card
5. Motor encoder signal B sent back to the ATMega328 (not sure what it is doing)
6. MEGA2560 will compare the encoder signals from the two motors and adjust the PWM signals and appropriate
7. Back to step 1
Is this the correct flow? I may start with sending move commands from 2560 to Motor Controller via I2C and move from there to controlling speed of each motor.
The steps you indicate concur with how I understand the DB1 design. Which then makes one pause to consider if this is really the best way. All the motor controller boards I possess can control 2 brushed motors, so all that is required is one motor controller board that can output the amps and volts required for the motors. Likewise only one microcontroller or SBC is all thats required to control the motor controller board, though it could easily drive more if required. (the number of pmw pins available may dictate the actual microcontroller or SBC selected for the task)
Also, my spiel on the encoder feedback was triggered by the fact that the code presented captured the encoder feedback on the separate boards that controlled the motor boards. But is encoder feedback going to be used to control the adjustments to the motors? For example, suppose that the bot navigation feedback was being provided by a pixy2 camera that was recognising spherical objects strategically placed at various points. Let's assume that the Bot was being directed to head directly to a specified spherical object that was in its sight. In this case the PID feedback to the motors may be by how much the pixy2's view of the object deviated from its centre position.
You have to ask, why is the bot being asked to move. In my case I don't see a use for an indoor bot, apart from experimentation purposes. I do see a use for an outdoor bot and I've concluded that encoder feedback wont be any good for my purposes where the bot gets tossed and turned by the grass and stones it encounters but the PID control is better provided by centimetre precision feedback from a couple of RTK GPS boards and a compass bearing.
So why would your DB1 bot move at all ? Is it to go on a predetermined patrol? Is it to go randomly about the place, but using sensor feedback to stop it bumping into to the walls and furniture? Is movement triggered by a voice command and in which direction will it then proceed. The answers to all this may dictated the navigation systems you put in place and the feedback you choose to provide to keep those motors directing the bot to where it should go.
Ha, I remember an old tv program when the robot was asked 'why' which made it go up in smoke and die. But probably you are just building it to experiment, and realise that this may well entail many changes to both the hardware and software along the route. The 'why' can come later, just don't ask your bot. 😀
Assuming that the only purpose your DB1 is to experiment with different choices and this may involve many changes to the physical components and the control programs used as one proceeds to develop and experiment, right now, and with the logic steps you indicate, it seems the first experiment is to see how to control the DB1 with multiple boards and the somewhat complicated process of encoder feedback that this may entail. 😎 It will be an interesting to see how the design does pan out. It may be that to start with, to experiment with a PID control for your bot to make it go in a straight line, a single microprocessor or SBC should be used. This could be developed on to move to a 2 board board later if and when the DB1 project is progressed by Bill.
or at least if a group of individuals on the forum would work together and move the project forward
I did suggest this very thing to those who seemed most active on the forum a long time back when the DB1 project stalled, but there was no response from anyone at the time. I think that most, like me, are developing their bots in a variety of ways, like using ROS, AI, GPS or whatever, and the DB1 project is of interest, but does not have a direct bearing on their projects. Maybe it would be worth your while to see if you can get those who are particularly wanting to progress the DB1 project to collaborate by putting up a separate post on this this subject.
Good luck with your bot and I hope to see the results of your first encoder feedback foray. 👍
Again, thank you for the input. My objective with DB1 is simply to learn how to develop an autonomous robot. What interested me with DB1 was learning mechanical, electrical and programming in one project. My first goal is navigation (primarily indoors) using sensors first and then moving to LIDAR with a mix of sensors. I purchased a TurtleBot3 as a way to learn ROS, LIDAR, and SLAM for navigation.
I think Bill’s current design is a bit complicated for a beginner and I like the idea of going back to a single microcontroller to talk to the motor driver. I see Cytron makes a 2 channel driver board (MDD10A) that I may purchase and look at using a single microcontroller to talk to the Motor Driver. Could I use a single ATMega328 to control the Motor Driver? Just thinking about it I’ll keep the MEGA2560 and replace the Motor Controller and dual Motor Driver PCBs with the MDD10A and a new Motor Controller card using a single ATMega328. I wanted to layout a new PCB so I can add a connected for an LCD display (to help troubleshoot). Any thoughts or recommendations?
If you already have 2 motor controller boards that drive one motor each then I would not suggest you go and buy a single board to drive 2 motors, as, in effect, the 2 motor board would just be the same as the 2 individual boards on one PCB. (but more handy I think if you don't yet possess the single boards).
I had a quick look at the Cytron web and I see there are links to their arduino based motor controller libraries and example code. I think that would a good start as you interact with their libraries to give code like motor.setSpeed(128); to drive the motor forward at half speed etc. This Library takes care of interfacing to the motor controller board which was connected with i2c with a grove connector to whatever. (at least the one I looked as was). I think that single ATMega328 the chip you mention is the one found in the arduino uno board. In that case I think you have 6 pmw pins and each single motor controller board only appears to require 2. But please do your research on this on the Cytron web and download all the instruction manuals and libraries sample code. I think you will then very soon have your bot driving in a straight line with encoder feedback as shown in the example I previously posted. Until you get some more sensors into the equation that may mean the bot drives straight into the wife's' big toe. I hope you are building a tough robot. 😀