DIY I²C motor driver with Arduino

[rubem]

Hi everyone,

I'm working on a module to control two encoder motors and two servos via I2C. The idea is nothing new, but I want the module to do all the "heavy lifting" so the client code is kept as simple as possible. I'm using the micro:bit as a client, but of course any I2C-capable device should work (ftDuino, TXT, TX-Pi, etc.). One of the main reasons I like the micro:bit is because of MakeCode, it can be simple and powerful at the same time. I'm also quite comfortable with JavaScript, and I've quickly created a simple custom library to help me with my tests:

Custom microbit library.png (43.58 KiB) 143275 mal betrachtet

In terms of hardware, the module should be inexpensive and use components that are readily available. I plan to use an Arduino Pro Mini clone, a generic DRV8833 board (I'm using a L293D for now), and a step-down converter for the module. I also have hardware questions, mainly regarding I/O and power lines protection. But I'll leave those for another post. And I have yet to draw the schematics. Here's my test setup:

Test setup.jpg (133.27 KiB) 143275 mal betrachtet

What should this module do? At least in ft, encoder motors tend to be configured in a very standard way: A limit switch that sets the home position, two motor outputs, and the counter input. Another common configuration is to use a second limit switch to signal the end position and ignore the counter. I've already tested these and the program works, but I stumbled upon my own limited knowledge of the fine details of actuators, interrupts and the like. Therefore the counter precision is low because I'm only stopping the motor when the limit is reached and nothing else. No dynamic speed control, no PID. In the future also want to be able to move the two motors in sync, improve the speed control (torque is quite low), control the servos and maybe create a learn mode with position slots saved to EEPROM. My I2C commands are:

Commands.png (164.66 KiB) 143275 mal betrachtet

I'm no I2C specialist at all, so if there are some known standards I'll be glad to use them. The code is published in this GitHub repo. It should be simple enough for the wizards among you to read without even testing it, I'm sure. But of course testing is very welcome as well

My main issues for the moment are: 1) Improving the motor precision; 2) A better way to send commands back to the micro:bit. AFAIK I2C is a multimaster protocol, but I'm not sure how to set up the micro:bit for it. For now I've used a pin to receive events from the Arduino (main.ts, line 38), but I think this is ugly and it also implies an extra wire between the module and the client.

I've already created another DIY module using an old two-wire ultrasonic module as the housing. This is simple enough (see the code at my repo). I have other modules in mind too.

I'll be very glad if this is also useful for someone, I hope some of you like the idea.

Many greetings from Southern Brazil,

Rubem Pechansky

[Karl]

Hello Rubens,
https://www.i2c-bus.org/specification/
https://www.circuitbasics.com/basics-of ... -protocol/
https://www.google.com/url?sa=t&rct=j&q ... 0fcsqmN1b6

[H.A.R.R.Y.]

Hi Rubem,

a dedicated motor driver is also on my list of projects, now you are way faster than me. However, the multimaster modes of the I²C are quite complicated, especially when arbitration needs one master to immediately revert to slave mode and answer the request!
Karl already gave you a link to the I²C-spec, this documents describes also the I²C-IRQ mechnism - rarely used but really powerful.

Eventually - but this might only be helpful to you if you omit the Arduino-IDE and compile with an "old school" AVR tool chain - you might find this lib somewhat useful: https://github.com/Zapfenkiller/i2c-lib

For your motors, and more generally for brushed-DC ones, some background could help you further
https://ftcommunity.de/ftpedia/2013/201 ... pdf#page=9
https://ftcommunity.de/ftpedia/2015/201 ... df#page=34
https://ftcommunity.de/knowhow/bauteildaten/motoren/
Unfortunately this all is written in German. But maybe you manage to get some idea of the inner workings of the motors and why your torque is so low.

Do you already use some SPICE (electronics simulator) to get some idea what happens inside the circuitry?
I ask because there is some secret that is recently overlooked and causes PWM drive to be less efficient as it is always stated or assumed. Underlying physics tell why ...

Regards
H.A.R.R.Y.

[juh]

Hi Rubem,

I haven't looked at your code yet, but hats off, your project already seems quite advanced!

I've been working on a similar motor driver + quadrature encoders + I2C + PID solution on and off for the last couple of years and only recently came back to the project, after having gained more experience with I2C and PID in some recent projects. My current approach is to use an ESP32 which has an sometimes overlooked, very flexible hardware pulse counter. It can be used to implement up to 10 hardware quadrature encoders hassle-free and without any load on the cpu. My early tests have shown them to be very fast and reliable. I primarily aim to run these kinds of geared quadrature encoder motors, but also have a more generic solution in mind to add quadrature encoders for ft mini and maybe other motors. Unfortunately, to my own disbelieve, I found that I2C slave mode on the ESP32 is a real mess (@MoG, you were unfortunately right about that), so that maybe I'll give up on I2C and go for wireless control via ESP-now.

When looking for Arduino/ATmega based solutions for quadrature encoders, it found that is important to look beyond the typical interrupt driven examples and instead go for the state machine type implementations which are more reliable and robust e.g. in case of jitter.

A couple of links for these kinds of projectsm, which might be of interest, the first one is of particularly relevant:

An Arduino-based firmware for I2C + 2 PID controlled DC motor drivers + 1 servo which looks quite advanced.

A firmware for the ATtiny2313 (!) for 4 quadrature encoders with UART output, which could be used to outsource the encoding task.

A similar project based on PIC µCs in combination with a tailor made module for the good old NC20 geared mini motors.

This slightly obscure but interesting board with very little documentation for the adventurous minded

And of course, Frans (fotoopa) does a lot of fancy encoder stuff with his FPGA boards which I are apparently much better suited that µCs for these kinds of tasks, but are a little beyond my current scope of expertise and ambition.

Best
Jan

[rubem]

Hi Karl, Harry, Jan (and others): I will answer you all, I'm very interested in the subject. I've been quite busy with other tasks and several new parts arrived in the meantime, But I'll be back here very soon.

Cheers!

Rubem

[rubem]

Hi again,

Perhaps I should have shown you this:

Designer_2021-04-26_21-02-32.png (103.05 KiB) 142984 mal betrachtet

The idea is to make some small modules to use with ft. They must be simple to construct, inexpensive, and encapsulate enough functionality so they are simple to use as possible for the controller's standpoint. So I'll try to break this topic down into questions, in no particular order:

1. Encoder motors. How to support encoder motors with precision similar to the TXT (and possible other controllers)?

I really don't actually need anything the TXT or the community controllers do not do already. My goal is simply to be able to control ft models, and the precision I achieve with the TXT is more than enough for my needs. (I assume that's true for most fischertechnikers as well.) I don't own a ftDuino, but I've checked MoG's code at GitHub. At a quick glance there doesn't seem to be anything much special about encoder motors except counting impulses at breaking the motors, I didn't find anything about PID or deacceleration. Is the ftDuino precision similar to the TXT's? If it is, maybe I don't really need PID after all, I din't know.

@Jan, thanks for the links. I still plan to keep everything within my comfort zone, so this means... Arduino for me I have a pair of geared quadrature motors that look almost identical to the ones you liked to, and I was using a pair of stepper motor holders (160528) with a drilled flat panel 31013 to hold them. (Of course you will use your 3D printer skills to make a top quality housing instead!) That was before I purchased 2 kits with original ft encoder motors, so the quadrature ones on the shelf now.

Also, motor synchronization is something that will be desirable, I wonder how the community controllers do it. Anyway, my results to date are not very precise, the counter always stops after the value I want (due to inertia, I believe). My DRV8833s arrived in the meantime, but I didn't test them yet, maybe they will improve this somewhat. I suspect my code is way too simplistic. This is the one area where I could really use some help...

2. Torque. How to achieve better torque with reduced speed?

I see this topic arises now and then at the forum. But to be fair that's not a priority for me now, it's just that it's a desirable thing for everyone.

> Unfortunately this all is written in German, But maybe you manage to get some idea of the inner workings of the motors and why your torque is so low.

@H.A.R.R.Y, thanks for the links, but they are way too technical to me. If dealing with it all is what I need in order to improve torque, I'll gladly leave it for now <off-topic> Unfortunately auto-translating PDFs is very difficult. PDF is a graphic format: Each line of text is inside its own container, so frequently the translation makes no sense at all. And in German, where long words are very common and composed of smaller ones, hyphens are guaranteed to make a complete mess. Maybe one day I'll ask the ftPedia guys if it would be possible to make the raw German text available. This would make it all much easier. It's a shame I can't read German, it's such a wonderful material. </off-topic>

3. Ready message. How to send the "ready" message back to the main controller?

I'm using a very crude method which is signaling the main controller (the micro:bit) with a pulse. This approach makes the micro:bit respond very quickly, but it has the disadvantage of using an extra wire and some circuitry (one transistor, two resistors). Using I²C multiple masters seemed to be a good idea, but now it looks it's complex stuff, and it may not even be the answer I'm looking for. So I'll probably give it up for now. The most obvious way would be to make the micro:bit poll the Arduino every N microseconds, I'll try that.

@Karl: Thanks for the links, especially the second one was just what I needed. I've read it all, it's a good read for an I²C newbie. Really helpful.

4. Standard I²C commands. Are there any standard commands for I²C I should use?

I'm creating my own codes to communicate between the motor module and the micro:bit (it's the "2CC" column at the spreadsheet above). I thought that there might be some standard codes around, I could use them if avialable. Won't make a difference in practice, since the I²C communication is already working (at least one-way).

------------------------

So that's about it, at least for the motor module, and thanks again for your help. What I need now is simply to be able to control and sync the ft encoder motors. But I can't deny I'm ambitious, I think these ideas could be made into a community project some time in the future. Of course if someone in the community likes the idea and wants to replicate these modules and improve on them, or even create some more advanced modules, I'd be delighted. I have many ideas...

[H.A.R.R.Y.]

Hi rubem,

we are not so way apart with the basic idea: Making some small modules that get versatile in usage. My idea is to mount one (or even two) motor drivers into one "Kassette 60" and use maybe I²C communication. Having also inputs it should be possible to read in stop switches as well as standard and quadrature encoders. The last gadget is necessary for a rather special and rare 9V-quadrature motor variant made by Knobloch based on the 135484.

Concerning the ft:pedia arcticles, I suggest to try an english explanation here in the forum and in this thread.

The internals of a brushed DC-motor (and from here just motor) are not too complicated. First you need to consider the two electric terminals. They connect to the commutator and this one finally to the coil windings on the rotor. The commutator just cares for the automatic change of one windings polarity. However, the coil consists of electric resistance and inductance. And when it moves, it produces electric voltage since the coils move in a magnetic field. Neglecting the inductance this leads to a very simple setup of a resistor being in series connected to a voltage source. With this you need two parameters to describe the setup:
* Ri = Resistance of the coil assembly (in the ft:pedia this is called dynamic resistance RDyn)
* VEMK = EMF which is the voltage produced
* The proportional constant = KU which gives the mapping from rotation speed to voltage produced
Let us assume some example data to be Ri = 10 Ohms and KU = 1 V / 1000 rpm for some calculations to follow.
This just means: Whenever this motor turns 1000 rpm its internal EMF gives 1 V, it produces 2 V at 2000 rpm ... 3.3 V at 3300 rpm. And it does not depend if the motor turns as a motor or is used as generator.

The next thing to consider is the mechanic side of the machine. Here we have the friction losses of the commutator, the bearings and some viscous drag to to air getting moved when speeding the rotor. Neglecting the viscous drag as well as eddy currents (since the rotor itself sees an AC voltage!) and putting all the remaining mechanic static losses into "bearing torque" this gives the minimum torque to run the rotor even if there no load connected to the output shaft. Then there is something that is called KI and describes the current necessary to produce a certain torque. The more torque the motor must drive, the more current it needs to draw. Let us neglect this KI thing (typically given as Nm / A) and assume the idle current is 50 mA due to "bearing friction" while on a certain load it draws 200 mA (the exact torque put out to the load does not matter but you immediately can tell this load torque is 3 times the "bearing friction").

Now connect this motor to a supply voltage, let us assume it is 9 V and have it idling. So this means there is a 50 mA current draw from the power source, runnig through the 10 Ohms of Ri. This leaves 8.5 V for the rotor. The rotor now speeds up to 8.5 V times KU reaching 8500 rpm.

The same motor but now on load wants 200 mA of current draw, just 7 V left for the rotor and thus just goes 7000 rpm.

Okay so far?

Now to the power stuff:
Ri is the place where electric energy builds up and gets turned into heat. In the idling example you get 25 mW of electric loss. To calculate for the mechanic loss you might need the torque and the rpm value. But this is not necessary. Just consider the EMF voltage and the current it hosts: It is giving 8.5 V * 0.05 A = 425 mW of mechanic energy - going also into some heat finally and means full loss.

Get the motor loaded changes the situation. The electric loss on Ri gets (10 Ohms * 0.2 A) * 0.2 A = 400 mW, the mechanic energy gets (9 V - (10 Ohms * 0.2 A) * 0.2 A) = 1,4 W. So this is barely the mechanic power produced but there are some losses to the "bearings" still. Well, assuming a constant loss of torque this means 50 mA of those 200 mA are for the losses and the load gets just 7 V * 0.15 A = 1,05 W. As expected, due to less speed the mechanic loss is somewhat less than when idling, here just 350 mW.

One thing should be kept in mind: The current running through the motor always follows ohms law!
Voltage across Ri divided by Ri gives the current and the voltage across Ri is always the difference between terminal voltage (supply) and EMF produced by the rotation. So this means the rotor adjusts itself to a certain speed until the current satisfies exactly the torque demanded. When voltage is applied the full 9 V / 10 Ohm = 0.9 A current runs since EMF = 0 V. The motor starts with maximum torque and while its speed increases its EMF does likewise. Differential voltage (Supply - EMF) thus gets lower and reduces current draw until euqilibrium of current draw to output torque is reached.

When will the motor start running?
Just being on idle means it start as soon as the idling current draw of 50 mA can be reached. So it should start at 0.5 V (10 Ohms * 0.05 A).
When on load it takes at least 200 mA to start it, here we get 2 V (10 Ohms * 0.2 A).
In practice this does not held true because the difference between friction when at standstill is higher than when in motion and some other effects.

The ft:pedia article does the explanation of the KI and torque stuff quite emphasized but in the last seven years I learned some more things. In addition to what the ft:pedia tells about the dependency of KU and KI and how those can get converted into each other it is just necessary to get motor current and EMF measured somehow to get all the motor data for a static operation point - withour having to measure any torque at all. But this is far beyond our scope here.

This all means: With a certain motor you can apply a certain torque to a reasonable load. The higher the supply voltage the higher this load could be (because there is plenty of voltage to heat up Ri) but the motor has some optimum torque to put out. Always running near topmost curren draw damages it. A reasonable load means the motor is run close to the point of topmost efficiency. Maybe you want to take a look into some ft motor data?
https://www.ftcommunity.de/knowhow/baut ... 93_neu.pdf
Leerlauf <=> Idling
max. Effizienz <=> max. efficiency
max. Leistung <=> max. power output (but not a good operating point)
Stillstand = stalled

If you like we could continue further into the topic. And, of course, if there are still questions then please ask! I bet there are some since this post cannot completely cover the ft:pedia scope. And this calculation model is somewhat simplified neglecting dynamic stuff or other annoying effects totally.

----------------

The overshoot of the motor position, when turning it off reaching the encoder terminal count, indeed is related to inertia. To overcome this the motor needs to get some stop command a little bit earlier and this needs to be well adjusted to the complete assembly of motor and its load - or you change to stepper motors.

----------------

Making this a kind of "community project" might need some more considerations. Maybe one thought needs to get spend on the operating voltage. Is 9 V just enough or do we need to prepare it also for the 24 V ft-motors being around?

----------------

Which Arduino are you using exactly?
I am sticky with Sparkfun ProMicro (clones) hosting an ATmega32U4. Similar to Arduino Leonardo, Teensy 2.0 and alike. It is fun to attach them to the USB to have my PC taking full control.

Regards
H.A.R.R.Y.

[rubem]

Hi H.A.R.R.Y,

we are not so way apart with the basic idea

I'm glad we are thinking similarly, maybe I'm on the right track here

Having also inputs it should be possible to read in stop switches as well as standard and quadrature encoders.

Take a look at calcPulseWithQuadrature() in my code, I used it in the past to work with quad encoders. Each motor has two encoder inputs (encoderA1/A2, encoderB1/B2). I have two encoder motors, I'll be glad to test them as the project progresses.

Concerning the ft:pedia arcticles, I suggest to try an english explanation here in the forum and in this thread.

That's what I call a great explanation! I can say I understood almost everything The conclusion is that the various ft motors have different curves, and your info suggested to me that using a table with PWM values for each motor type would probably give better results than linear values 0-255 (these should also be available for other cases). For example, let's suppose that for the XS motor the optimal 8 PWM values to emulate a more-or-less linear response should be 50, 87, 112, 180, 211, 233, 247 and 255, while for the XM motor threy are, say, 31, 56, 70, 91, 132, 149, 209, and 255. Obviously I just made up these values. The controller should then inform the motor type to the Arduino, so the optimal motor curve is selected for it. And these values could even be configured via I²C... As I said above, this is not my priority number one now, but I'll certainly will implement something like it.

To overcome this the motor needs to get some stop command a little bit earlier and this needs to be well adjusted to the complete assembly of motor and its load

I could come up with some algorithm from the top of my head, but I suspect I'll be reinventing the wheel. Here's my million dollar question... How does the TXT do it? And the ftDuino? And the TX-Pi?

or you change to stepper motors

Support for steppers is on my to-do list, but I think PID is a must. I'll leave it for the experts

Making this a kind of "community project" might need some more considerations. Maybe one thought needs to get spend on the operating voltage. Is 9 V just enough or do we need to prepare it also for the 24 V ft-motors being around?

More powerful motor drivers will be necessary, but I have no prejudices at all. I'll be glad to incorporate 24 V too sometime.

Which Arduino are you using exactly?

I didn't know about the Pro Micro, looks interesting because it opens up more possibilities and it's a great candidate for a small controller. (I'm calling the "main" microcontroler the "controller" or "client" for now, in my case it's the micro:bit.) I'm using generic Nano (see pic of my test board) and Pro Minis because they are as cheap as you can get. The Pro Minis are easily programmed with an FTDI converter:

FTDI.jpg (88.73 KiB) 142893 mal betrachtet

Thanks again for your quick and detailed answer!

Best regards,

[juh]

Hi Rubem,

I very much like your module approach, your sketches look really cute. I'm sure it will be a fun project and I know the feeling that it is hard to keep up with all the ideas only too well!

This thread is growing fast and adresses a couple of interesting topics. I'll pick out only a few.

1. How to talk back to the I2C master when the motor's controller task is finished, e.g. after having arrived at a given position or speed?

I agree that an additional line is not elegant. However I expect it to be much easier and reliable than other aproaches,e.g. I2C multi master or the master constantly polling for results via I2C. Many I2C chips chose this solution by providing an additional interrupt pin, e.g. the MCP23017 and PCF8574 I2C port expander chips. I'll probably chose that approach in my project.

2. Quadrature code

Your quadrature code uses the conventional method of evaluating signal B when a flank at signal A occurs. As I mentioned above, this approach is easy, yet unreliable in case of direction turns or jitter, e.g. when the motor comes to a stop (this page in German has a very good analysis). A state machine approach is more reliable and easy to implement, I linked an ESP32 lib above, this is a good one for Arduinos: https://github.com/brianlow/Rotary

3. Which platform to use

You are perfectly right to choose the platform you feel comfortable with, I do the same when I choose to not go for FPGAs . I just wanted to mention that ESPs can be programmed with the Arduino IDE, so the step is just a small one, many sources will compile on both platforms. They cost the same, but offer so much more possibilities by default (WiFi, BT, touch sensor pins, PWM on all pins, etc. pp.).

4. Motor synchronization / stopping at exact position

I'd expect PIDs to solve this problem, particularly if Harry's points are taken into account, too. Without PIDs, overshoot can be countered by putting the motor driver in slow decay or brake mode, the datasheet usually has a input logic table for that. However, without PID it will remain a problem, particularly with geared motors.

5. Speed considerations

I intend to support up to 4 quad encoder motors in my project. The geared motor model I linked above generates ca. 10000 flanks per second at full speed (240 RPM x gear ratio 1:57 x 11 polarization impulses per turn x 4 quad signal changes). I didn't do the math, but I doubt that ATmega chips will be able to reliably keep count of 4 x 10000 signal changes per second, and at the same time handle I2C requests, and do PID calculations. To solve that problem, I've been looking at a number of alternatives like FPGAs or dedicated quad encoder chips, which all did not turned out as viable options for my purposes and skill set and put that project on hold. That's why I was so excited to find out only recently that the ESP32's pulse counter can be used as a hardware quad encoder.

Here is my current test setup with a LOLIN32 OLED module, an I2C DC motor driver (Adafruit featherwing motor module) and a hall sensor for counting turns. As you can see, you were right about the printed housings . My early results show that the pulse counter reliably counts all quad steps at all speeds. My next tests will be repositioning tasks to see if it keeps reliable when changing directions repeatedly.

web_DSC_3763.JPG (94.83 KiB) 142823 mal betrachtet

Best
Jan

[rubem]

Hi Jan,

I very much like your module approach, your sketches look really cute.

Thanks! I hope I'm getting somewhere with all this

I agree that an additional line is not elegant. However I expect it to be much easier and reliable than other aproaches,e.g. I2C multi master or the master constantly polling for results via I2C. Many I2C chips chose this solution by providing an additional interrupt pin, e.g. the MCP23017 and PCF8574 I2C port expander chips. I'll probably chose that approach in my project.

I don't know anything about these chips, won't the connection to this additional pin also imply an extra wire?

Quadrature code -- this is a good one for Arduinos: https://github.com/brianlow/Rotary

Thanks, I'll take a look at it.

I just wanted to mention that ESPs can be programmed with the Arduino IDE, so the step is just a small one, many sources will compile on both platforms. They cost the same, but offer so much more possibilities by default (WiFi, BT, touch sensor pins, PWM on all pins, etc. pp.).

Now I'm intrigued! But even with the same IDE, I fear ESPs are more complex. I admit I'm a bit reluctant to deal with more complexity now... My focus is still on keeping things simple for everyone. What I could do, however, is to replicate something done and tested by others and collaborate from there, this might be even simpler than my current approach Which hardware should I use, exactly? And... would you be willing to share your code?

Motor synchronization / stopping at exact position -- However, without PID it will remain a problem, particularly with geared motors.

I still wonder which approach is used by the existing controllers. I understand the inner workings of the TXT are not publicly available, but the ftDuino code is on GiHub, I didn't see PID in it.

Speed considerations. I intend to support up to 4 quad encoder motors in my project.

Supporting four encoder motors at such high speeds with a single processor is way too advanced for my goals, but, as I implied above, I trust others more than myself in this regard. (In fact, in my dream community project, I'd take care of the usability and design aspects and leave the software and hardware parts to other people.) My original plans are much more modest: Several identical small modules, each processor taking care of two ft encoder motors and two servos. I²C addresses would be configurable via jumpers or DIP switches.

Here is my current test setup

Beautiful! Yes, I've been an admirer of your designs for ft for a long time in Thingiverse. Keeping track of pulse counts at this speed is really remarkable -- I'd even think that at 10 kHz some kind cable shielding would be necessary...

Please let me know your thoughts, I'd also looking forward to @H.A.R.R.Y's thoughts as well.

Best regards,

[rubem]

Hi again,

The diagram below (not a schematic, it's just a drawing) shows an example of what I have in mind. This is an hypotetical model with one encoder motor, an S motor with two limit switches, an I²C ultrasonic module (not the ft one) and a small OLED display:

Diagram.png (99.72 KiB) 142741 mal betrachtet

The ugly controller at the bottom has a micro:bit inside, but any controller with an I²C interface should work, hence the "ghost" TXT there. I wouldn't use a TXT, but the possibility is there.

[H.A.R.R.Y.]

Hello out there in the wild,

The conclusion is that the various ft motors have different curves, and your info suggested to me that using a table with PWM values for each motor type would probably give better results than linear values 0-255 (these should also be available for other cases).

I do not know what exact non-linearity you might have in mind. Maybe it is the stuff I excluded from the simple modelling? Especially the thing is that the mechanic load (torque) dictates the current draw and there is the idle torque that is included there. Maybe it is this difference that causes the motor to need some minimum voltage before it starts turning? In any case such characteristics depend on the motor and its load. Way back in 2006 (or 2007) I build a simple robot platform that used two DC-motors to propel the machine. Encoders (non-quadrature, of course) and motor current measurement I used to control the speed of the two motors. But not by a PID (like most would do) but simply by knowing the motor mode parameters and having the micro to calculate the necessary stuff just from motor current draw and supply voltage data. And, it worked out very well keeping the thing on a straight track. Encoders only were used as odometers and to adjust the target motor into the motor model calculation speed slightly.

Eventually you could do something similar and predefine typical motor model parameters into the design. Just by a command you select the appropriate set of parameters for a certain motor. And there might be an "expert mode" to freely define a set for some motor not in the database already.

Personally I will give my project 4 feedback inputs to any motor channel. 2 for stop position switches and 2 for quadrature encoder. Unused ones (not for motor control) could be used as general purpose inputs to detect other stuff in the machinery. Some operating mode configuration should be possible. Of course, those inputs need to be safe against 9 V or even higher voltage accidentally (or maybe intentionally) applied.

Since there are several interesting ideas also here from juh, I think I should go into some details of how a motor is PWMed?
But just before I go there: 10000 Impulses of an encoder per second gives 1600 CPU clocks with a 16 MHz quartz between the edges. It could be feasible to even catch the events from two such encoders with just an Arduino (if it is driven this fast). Of course, this means to write interrupt routines and use pin change interrupts. But in the far end such an ESP32 or anything with dedicated hardware might be a better solution not slowing down the micro so much. If it will not work this way at all there is the CPLD or even FPGA approach - but only on my personal lab bench.

Okay, now to PWMing the motor.
Well, with your setup you want to use an H-bridge to control the motors direction, right? I assume you are familiar with the basic schematic so I can skip some schematic picture here. When all 4 H-bridge transistors are off (non-conducting) then there is no current into the motor. The same is when just one transistor is in the on-state (fully conducting). Two transistors being on the same side (left or right) is a nono as well as all 4 transistor being on at the same moment. I think this is clear because this will short the battery or other supply and causes damage. To turn the motor clockwise you might want to put the upper left and lower right transistor to their on-state. Inside the motor things happen as explained in my last post.
You please remember the paragraph

One thing should be kept in mind: The current running through the motor always follows ohms law!
Voltage across Ri divided by Ri gives the current and the voltage across Ri is always the difference between terminal voltage (supply) and EMF produced by the rotation. So this means the rotor adjusts itself to a certain speed until the current satisfies exactly the torque demanded. When voltage is applied the full 9 V / 10 Ohm = 0.9 A current runs since EMF = 0 V. The motor starts with maximum torque and while its speed increases its EMF does likewise. Differential voltage (Supply - EMF) thus gets lower and reduces current draw until euqilibrium of current draw to output torque is reached.

Now you turn off one (or even both) transistors while the motor is running. Current through the windings disappears quite fast (invers diodes) and then inertia puts the stored kinetic energy into the load and friction losses and so on until everything comes to a stop. This will take some time and depends on several parameters, namely the inertia, the original rotating speed and the losses. The more inertia, the more speed and the less losses the longer the deceleration phase takes. May I assume this is no news I tell you?

Now consider the same situation. Upper left transistor is on, lower right transistor is on and the motor runs at a certain speed. Turn off the upper left transistor, maybe wait some dozens of microseconds and then turn on the lower left transistor (while the lower right transistor still is on). Now the motor is short out. Its EMF still corresponds to the rotation speed (maybe 7000 rpm and then decelerating). This voltage comes across the motor resistance Ri and the transistors. Let us assume MOSFETs with just a fraction of an Ohm, so neglect this small extra resistance. In the example we get 7 V from the 7000 rpm and thus 700 mA driven to the 10 Ohms. The motor now works as a generator! This takes lots of kinetic energy back from the rotating inertia and brakes the motor way faster than the pure mechanical losses in the previous case. Of course, the braking effect lowers with rotation speed getting lower. But it reduces the braking distance when the motor needs to get stopped. Some experts drive the motor by reverse voltage risking damage to the circuitry and the gears, while the extremely high current peaks also might negatively impact the magnets.

PWM drive now works by just turning one of the two transistors being in on-state off for a short while. What exactly happens depends on which transistors are pulsed (pulsing just one is sufficient while the other stays on). Let us consider the upper left transistor is continuously on and the lower right transistor is pulsed by the PWM. While this transistor is on there is current forced through the winding, the rotor is accelerated a bit. While this transistor is off the motor carries no current, the rotor inertia gives away a bit of the energy and the rotor decelerates a bit. The current draw is pulsed according to ohms law and the average supply current still depends on just the load. If the motor needs 200 mA average on its load, it will need this 200 mA independently from its speed. This means that you have way higher current peaks for shorter time in the on-phase to get the overall average current draw satisfy the mtors needs.

Now consider the motor is running and still the lower right transistor gets PWMed. The upper left transistor gets turned off. The rotor will idle due to no current is forced into or drawn out of the motor. Now the lower left transistor is turned on permanently. While the motor is shorted, it delivers current through the circuitry and gets braked noticeably. This stops as soon as the lower right transistor receives its off-state. The motor idles now and the rotor just slows down a little bit by the mechanical losses only. This cycle repeats and thus the motor gets decelerated (braked) further. The longer the on-state takes, in relation to the PWM period, the higher the braking force and the faster the motor comes to a stop.

All this means, PWM is able to control the speed of a motor (by reducing the average supply voltage) as well as controlling the braking of a motor. To achieve this the PWM always switches the motor between either "drive / idle" (by a diagonal pair of transistors) or "brake / idle" (by the either the upper or lower row of transistors). If you PWM the bridge so, that one side connects the motor to a power rail and the other flips over also between power rails you just waste energy because you drive and brake the motor once during a PWM period - it is as if you drive your car with brake pedal and accelerator pedal applied simultaneously; or even better: Consider you would ride your bike and pull the brake while you are cycling. I do not know the schematic and the bridges you use for your setup so I cannot tell you if eventually this particular effect lowers the motor's torque like you reported earlier.

One further point that is not obvious from your diagramm:
When applying more than one motor controller you will suffer from GND loops! The motor power supply needs V+ and GND to get distributed and then you have the communication also needing some GND reference. Using the PWR GND of the motors could eventually give hazzle with GND shifts between the devices (especially when higth current draw occurs). Daisy Chaning the pwoer rails through the devices is also limited by current capability of the PCB traces and wires. So I think here some clever trick is necessary to get rid of this problem. Eventually refrain from using I²C and step back to the good old MIDI interface hardware using UART and optocouplers.

Please be aware, that a PWM driven H-bridge (especially when PWM by SW emulation with just 250 Hz or so) will not save any energy from the supply. From motor view the PWM-H-bridge controls the supply voltage (and the braking current). But from the supply side there is always the full energy drawn by the motor-and-H-bridge combination because the voltage reduction does not happen efficiently enough and there is always the full motor average current draw on the supply (rippling into the motor by short but high current peaks). And the most overlooked effect is that the difference between supply volateg and average motor voltage (if PWM is less than 100 %) times the motor current is heated away in the motor resistance. So at low enough PWM and hgih enogh motor load the motor will get way warmer than with sufficient low direct voltage supply.

For my desgin I am really on the trip to first apply an efficient and high frequency DC/DC buck converter to lower the bridge supply to where it is needed and then use the H-bridge non-PWMed just to control the direction of the motor (or braking it into a stop). This really reduces energy draw from the supply everytime the motor is not running full speed. Depending on the usage this might even prolong battery operation. The ultimate gadget would allow for recuperation when braking but with the small ft-motors a recuperation effort does not make any sense.

What do you think on this all?

Regards
H.A.R.R.Y.

[rubem]

Hello H.A.R.R.Y.,

I do not know what exact non-linearity you might have in mind.

Sorry, I didn't really explain what I had in mind. I refer to the fact that the 8 speeds in the TXT do not behave linearly. From a user's point of view, speed 4 should mean something around half the full speed; speed 2 should 1/4; speed 6 should be 3/4; and so on. However this is not the case. I'm suggesting a simple transfer table so as to improve this perceived linearity when using discrete steps. I hope it's clearer now.

Personally I will give my project 4 feedback inputs to any motor channel. 2 for stop position switches and 2 for quadrature encoder

Yes! In motor-driver.ino I'm also reserving exactly 4 inputs for each motor: encoderA1, encoderA2, limitA1, limitA2 and the same for motor B.

Since there are several interesting ideas also here from juh, I think I should go into some details of how a motor is PWMed?

May I assume this is no news I tell you?

Right, I've been dealing with motors and H-bridges for some time now. I even published two Arduino-based controllers on the picture pool years ago. But my technical knowledge does not come even close to yours

PWM

Thanks for this class today

I do not know the schematic and the bridges you use for your setup

Just standard Arduino hobbyist stuff, using a L293D connected directly to pins D5/D6 (motor 1) and D3/D9 (motor 2). I did get the DRV8833s, but the circuit is still unchanged.

When applying more than one motor controller you will suffer from GND loops!

Aha, I remember those from the 80's when I dealing with analog circuits.

Eventually refrain from using I²C and step back to the good old MIDI interface hardware using UART and optocouplers.

As I stated above, I always prefer to leave these matters to the experts. I would love to have the hardware and low-level software parts done by the guys who really know what they are doing

For my desgin I am really on the trip to first apply an efficient and high frequency DC/DC buck converter to lower the bridge supply to where it is needed and then use the H-bridge non-PWMed just to control the direction of the motor (or braking it into a stop).

This is really interesting. Speed control with more power! Thats a cool idea. I look forward to the results.

Best,

Rubem

[rubem]

Oops --- must have pressed Enter too soon, sorry...

[rubem]

Okay, so here's some of my vision for the whole thing:

The areas that interest me most with this project are the design and user experience. I want to create a set of modules that are as easy to use as possible, so with just a few blocks of controller code powerful things can be achieved. That is, I want to target builders instead of programmers. I think this is an exciting area, but it seems this is only possible today with the Electronics Module, although I don't have a hands-on experience with it because I don't own one. Sometimes I think that it's paradoxical that our hobby is now more difficult than decades ago... I see that some of the most experienced among you are (and justifiedly so) proud of their ability to make a model work with no computing at all and/or minimal electronics. Others resort to analog electronics and/or the old electromechanical controls or the Silberlinge to make a model work. I guess this is because, after figuring out all the details and the mechanics of a model, the fun part seems to end, at least for some. Then comes the "boring" part, which is programming. Am I guessing right?

I believe there is a solution to ease this problem a bit: "decoupling" the hardware and software into layers: at the lower level, "Smart" modules do the heavy work (deal with motors, encoders and other hardware-related stuff) and may be interfaced via I²C (or whatever interface is preferred) via simple commands -- something analog to a "back-end" API, if you like. Some possible commands are shown in the table on my first post. The main controller (the "front-end layer") is close to the user, so it takes care of the model logic via simple blocks ("low-code"). At the limit, these modules could even function by themselves with no programming at all (i.e. "no-code"), but that's much more complex and it's not my first objective here.

Too many analogies with web-based systems, I know...

Cheers,

[rubem]

Here's an idea in the form of another pseudo-diagram, showing a way to use these DIY modules to replace the TX/TXT -- for existing models. This would be for the Automation Robots kits.

Automation robots.png (145.89 KiB) 142322 mal betrachtet

[H.A.R.R.Y.]

Olá rubem!

Your setup is quite clear and nice. It is exactly this "building block" approach that I am also thinking about. To me it does not make much sense to put every hardware function (motor driver, digital or analog inputs and so on) into one huge and pricey core unit. This is also not the way how automated plants work. Making the control grid from certain building blocks gives way more flexibility - much the same our ft parts give us with mechanic setups. And the most annoying thing is that there is really no motor driver around that suits my needs and requirements of reading back the motor current draw. Not even the ftDuino is capable of it. So this is why I make my electronics myself to get what I really want.

Yes! In motor-driver.ino I'm also reserving exactly 4 inputs for each motor: encoderA1, encoderA2, limitA1, limitA2 and the same for motor B.

Thumb UP! (We still lack this modern emoji stuff here in the forum!)

Then comes the "boring" part, which is programming. Am I guessing right?

To me personally it depends on what I am doing or want to show. Sometimes I find it way easier (and faster done) to take a motor and a few switches for controlling some mechanic stuff. Playing with marble runs (e. g. this one) I just do not need any logic. A motor pushing the lift mechanism and some tracks guiding the marbles back down. As simple as possible. No joke: When I was on an exhibition there really were several people asking which controller I am using for the machine! Well, there was another challenge being in need of some motor control for reversing and some pausing at the end positions. Of course one could do it with a computer. My solution was to exhibit the exotic and really rarely used geneva mechnism: Hebewerk. Of course, this used two motors and might be less energy conserving than a slowed down microcontroller just eating a few milliamps or some dedicated hardcoded logic using "Silberlinge". Or even some CPLD or FPGA could host the control logic. So I think everyone has his/her own ideas, skills and needs that lead to an individually optimum solution. And programming is not always the boring part. The most boring thing is removing the dust ...

Sorry, I didn't really explain what I had in mind. I refer to the fact that the 8 speeds in the TXT do not behave linearly. From a user's point of view, speed 4 should mean something around half the full speed; speed 2 should 1/4; speed 6 should be 3/4; and so on. However this is not the case. I'm suggesting a simple transfer table so as to improve this perceived linearity when using discrete steps. I hope it's clearer now.

Ah, I see. This, I think, is due to how the motor works. The effective voltage the machine receives depends also on current draw and I think the characteristic (mapping table) also depends on the load the motor has to drive. At least there is some residual voltage the motor needs to start turning and I think this must be met be sufficiently high minimum PWM. PWM sets the average voltage the motor gets. So your linear assumption means being linear in rotation speed. But due to the effects 50 % of PWM never gives 50 % of speed but always less. You always need to apply more PWM and this in fact depends on motor current draw. You have to compensate the inner voltage loss across Ri. Maybe quite simple to understand: Full voltage to the motor (PWM = 100 %) gives topmost speed but only in terms what is achievable on the mechanic load (torque). But wait, maybe it is also due to your motor control; I think the PWM you do the wrong way with the L293D.

Right, I've been dealing with motors and H-bridges for some time now. I even published two Arduino-based controllers on the picture pool years ago. But my technical knowledge does not come even close to yours

Yes, I remember. The bridge and the Custom Arduino Interface. (I am so glad we have again a working search function.) This project of yours does not use L293D. It is something else, resembles me to stuff found in servos some decades ago.

Thanks for this class today

As I stated above, I always prefer to leave these matters to the experts. I would love to have the hardware and low-level software parts done by the guys who really know what they are doing

You are welcome. Don't you want to also get one of the experts who knows what and how to do?

> For my desgin I am really on the trip to first apply an efficient and high frequency DC/DC buck converter to lower the bridge supply to where it is needed and then use the H-bridge non-PWMed just to control the direction of the motor (or braking it into a stop).

This is really interesting. Speed control with more power! Thats a cool idea. I look forward to the results.

No my dear, this will not give more power to the motor. It might just conserve some precious energy from the supply and make a mobile device running a bit longer off its batteries.

And now to the issue you have with power and PWM drive:

Just standard Arduino hobbyist stuff, using a L293D connected directly to pins D5/D6 (motor 1) and D3/D9 (motor 2).

Yep, that is the root cause. You remember

All this means, PWM is able to control the speed of a motor (by reducing the average supply voltage) as well as controlling the braking of a motor. To achieve this the PWM always switches the motor between either "drive / idle" (by a diagonal pair of transistors) or "brake / idle" (by the either the upper or lower row of transistors). If you PWM the bridge so, that one side connects the motor to a power rail and the other flips over also between power rails you just waste energy because you drive and brake the motor once during a PWM period - it is as if you drive your car with brake pedal and accelerator pedal applied simultaneously; or even better: Consider you would ride your bike and pull the brake while you are cycling. I do not know the schematic and the bridges you use for your setup so I cannot tell you if eventually this particular effect lowers the motor's torque like you reported earlier.

This means that PWM control cycles the bridge to get High-Z (high impedance state = transistors off) when PWM is "off" at least on one side. The L293D can do this but you just give it two inputs "A" and "B". I bet you just tied ENABLE to Vcc having the respectively selected transistors always in their on state. So on each side it always is low-Z (low impedance = transistor on) driving either power supply voltage or GND to the motor terminals. Like in the cyclist example your setup exactly cycles while you pull the brake. Please take a look into a datasheet of L293D (links to TI but there are more manufacturers around). There you will find not only "IN1" and "IN2" to control the bridge output voltage but also an "ENABLE" to control the drive state (low-Z vs. high-Z). The "IN1" and "IN2" get the static selection of mode control: direction (01 / 10) or brake control (00 / 11). The PWM needs to be connected to the "ENABLE" input! So you need to modify your setup giving 3 wires (and one is the PWM) instead of just 2 wires per motor to the L293D. The same is true for other L293 variants and L298 and whatever is similar.

When you want to start with DRV8833, please also check its datasheet first to find out how to PWM the bridge the right way.

Cumprimentos
H.A.R.R.Y.

[rubem]

Hi H.A.R.R.Y,

Your setup is quite clear and nice. It is exactly this "building block" approach that I am also thinking about.

Good, that's how it should be IMO. However a second look at the last diagram I've uploaded tells me there is still too much wiring to do. Maybe that's unavoidable... but I remember juh uploaded photos of some clever modules that could be stacked upon each other. @Juh: couldn't find those here or in Thingiverse, weren't they called "we fish" (or the equivalent in German)?

So I think everyone has his/her own ideas, skills and needs that lead to an individually optimum solution. And programming is not always the boring part.

Absolutely! For many people, programming is THE fun part, and that's how it should be. I have nothing but respect for all kinds of hobbyists. As it is often repeated here in the forum, everyone should pursue their hobby the way they want. (This should be displayed as rule #1 somewhere.) But I still want to make things simple for those who think programming looks too much like work... That's just how I feel sometimes Oh, and kudos for the absolutely amazing-looking Kugelbahn with no programming!

You are welcome. Don't you want to also get one of the experts who knows what and how to do?

Yes! As stated above, I'd more than happy to leave the hardware and software details to you and/or others who want to.

This project of yours does not use L293D. It is something else, resembles me to stuff found in servos some decades ago.

Right, those were BA6418N or BA6218 chips scavenged from some old HDDs or floppy drives...

this will not give more power to the motor. It might just conserve some precious energy from the supply and make a mobile device running a bit longer off its batteries.

It seemed to me that lowering the voltage for speed control would be more efficient than PWM for the same speeds. But that's probably because the PWM implementations I've been working with are far from ideal...

I think the PWM you do the wrong way with the L293D. ... I bet you just tied ENABLE to Vcc having the respectively selected transistors always in their on state. ... The PWM needs to be connected to the "ENABLE" input!

Yeah, exactly. And without questioning, because that's just like 98% of people in the Arduino world say it should be done

When you want to start with DRV8833, please also check its datasheet first to find out how to PWM the bridge the right way.

I'd rather ask Juh, he's already done it and he should know how it works. BTW, below are the DRV8833 modules. I also bought these two small step-down converters to get 5V out of 9V. They measure just 18 x 12 x 4.5 mm, they fit anywhere. The chip is called MP2307DN. Didn't test anything yet, though.

DRV8833.jpg (95.14 KiB) 142213 mal betrachtet

Abraços,

Rubem

[MasterOfGizmo]

The internals of a brushed DC-motor (and from here just motor) are not too complicated. ... Neglecting the inductance this leads to a very simple setup ...

Consider you would ride your bike and pull the brake while you are cycling.

All your colorful explanations miss the fact that the motor is an inductor. Switching its power supply between different voltage levels doesn't mean you are switching the motor simply on and off. Instead you are dealing with the residual energy stored in the coils of your motor.

The funny thing is that the data sheet you've been linking to https://www.ti.com/lit/ds/symlink/drv8833.pdf has more information on exactly this topic in section 7.3.2 "Bridge Control and Decay Modes". The important sentence in that chapter is

"the inductive nature of the motor requires that the current must continue to flow."

. This energy must go somewhere and if you don't shorten the outputs in the off phase of your PWM then the power goes e.g. into the body diodes as explained there. Your datasheet explains both cases and calls them fast and slow decay modes. But it's not simply "right" and "wrong" as you suggest.

[rubem]

Here's an much better drawing of the "alternative Automated Robots" diagram. I also shows that even with all 4 motors and 8 push-buttons (the 4 models in the kit never use them all at the same time), there still would be room for additional hardware: four servos, 6 sensors and 8 LEDs. The LED/sensor module should support up to 8 inputs and 8 low-current outputs. Again, all this is still on the ideation phase, of course.

Automation robots 2.png (222.56 KiB) 142187 mal betrachtet