Seite 2 von 3

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 17:26
von H.A.R.R.Y.
Hello MasterOfGizmo,
MasterOfGizmo hat geschrieben:
30 Apr 2021, 16:04
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.
Nope, Sir, it is not. I agree that inside the motor there is this rotating packet of coils. It is each coil of that packet that adds some inductance. So a motor has got some inductive behavior and, of course, some path for the current needs to get provided. With a simple one transistor stage on an inductive load (like for a solenoid or an unidirectional motor drive or one coil of a unipolar stepper or ...) you find always this inverse diode across the load. It is this diode that takes the inductive current when the magnetic energy comes back into the circuitry. With MOSFET H-bridge (!) motor drivers you are right, the body diodes need to take the current and dissipate some heat. With bipolar transistor bridges diodes are mandatory. Some higher power MOSFET designs also apply external Schottky-diodes to keep the power dissipation away from the body diodes. The L293D, being bipolar at its heart, already has the diodes integrated, exactly for this purpose.

There is some literature around (and also it is mentioned in the data sheets), that a shortage across the inductive load will also recirculate the current and it will do this with way less energy loss since the residual drop voltage drop is lower than that of a diode. And I agree to what is written there in the data sheet.

BUT:
  1. While a capacitor stores its energy by an electric field and thus a voltage, an inductivity stores its energy by a magnetic field and thus a current flow. With a capacitor the resistance between its terminals needs to be as high as possible, the lower this resistance, the more energy gets lost. With an inductivity it is quite the opposite and the resistance shall be as low as possible in the whole circuit to keep the current running.
  2. While the recirculation current is decaying it still generates some torque in case it is a motor (even with a stepper).
  3. With steppers you want a very long decay (lowest resistance losses) while the coil shall be powered. In case the next step is commutated this particular coil needs to get free of current as soon as possible and for this you want the shortest possible decay, highest resistance.
  4. There are special circuits that do not use a standard diode for recirculation but some zener with higher voltage. This indeed shortens the current decay way further. Well, this is used typically with unipolar drivers, not H-bridges.
  5. The DRV8833 is primarily intended as a stepper motor driver. Stepper motors designed for chopper-drivers usually have very low resistance and some inductivity. A chopper driver typically takes several kHz of frequency to controll the current draw through the stepper winding (hence the DRV8833 sense resistor capability).
  6. When the recirculation current died out you still have the EMF generated. Now, at this moment the motor will start to work as a generator, the current direction is opposite to its "motor state" and the electric energy produced comes from the movement.
A typical ft-motor (an "S-motor") I once put into my RLC bridge and figured out it has roughly 150 uH. And it had roughly 10 Ohms. According to physics this leads to 150 uH / 15 Ohms = 15 us time constant. With each time constant the current falls down by 63 %. The external circuitry with its voltage losses looks like some additional resistance shortening this time further. So with this data the recirculation current dies out at roughly 75 us at the latest. After this moment the DC motor starts to work as generator and you just brake the rotor when it is kept shorted. One could use such a short out of the motor to take the recirculation current but this needs precise timing to not get the motor work as generator unintendedly! Not providing any recirculation path will boost the energy into the parasitic capacitors and thus provide some huge voltage. So for the most purposes the inverse diode across the load will do.

And now consider the max. 75 us (exact value depends on motor data and circuitry choosen!) versus the 4 ms period when using SW generated PWM drive. Most of the "PWM off" time the motor is working as a generator and thus actively braking instead of idling until it receives the next kick of energy. Okay, the exact ratio also depends on the PWM ratio. To get a PWM H-bridge driver somewhat conserve some energy it has to be controlled by a PWM of several kHz at least. And then we have got lots of ohms due to the motor winding that just disspates away the electric energy as heat. Please take a look into switched regulator designs (namely the "buck" kind) to understand that resistance in the current storage path needs to be as low as possible if you want some noticeable efficiency.

There is one more thing to tell. Please consider the L293D internal setup applying the inverse diodes. When this kind of bridge is turned off, the motor current can idle through the diodes into the power supply. This is lots of voltage against the current must be driven and this gives a pretty fast decay. Please compare this with the respective pictures in the DRV8833 spec. Again, the DRV8833 is targeting primarily bipolar stepper applications and it could also serve DC motors. But you need to understand the differences.

Maybe you now understand that the "slow decay" mode is wrong when a brushed DC motors is PWMed for a certain reduced speed, the PWM commands "apply power / idle". But it could be used when you want to brake the thing to a stop - but please, here the PWM commands "short out / idle".

Oh, by the way: Some years ago I put an 8 Ohm speaker (which undoubtedly also has some winding and such an inductivity inside) as load resistor on a BC547 without any diodes. The circuitry you find across the web and in lots of (semi-)professional literature. No inverse diode and no way to "keep the current running". It is a real "short decay" mode exploited here. And still it works well when I use it today. Strange, isn't it?

Regards
H.A.R.R.Y.

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 17:54
von H.A.R.R.Y.
Olá rubem,
rubem hat geschrieben:
30 Apr 2021, 15:21
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.
That is okay for me. But please do not assume I will work on this particular project with highest priority. I have some other stuff that I want to play around with.
rubem hat geschrieben:
30 Apr 2021, 15:21
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...
Not completely. PWMing a motor done to simulate it some lower supply voltage just dissipates more heat into the motor winding. In fact - and especially with low PWM frequencies - the motor resistance Ri is taking it. It is hard for me to describe here and if you carefully read my post on how the motor internal basically work, you might get the idea why it is this way. If you calculate, remember that the power gets Ri * I². I you get from the simple calulation given earlier. Then some integration across it which simply means you multiply it by the duty cycle of the PWM and then you see what happens. But, as you explained, you would like to leave it to more advanced hobbyists what I respect. Maybe someone else here is also interested in this topic - that's why I still highlight it.
rubem hat geschrieben:
30 Apr 2021, 15:21
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 :D
Without any PWM drive and wanting to hard brake the motor this scheme is correct to use, of course. In any other case you now know what to do. ;)
rubem hat geschrieben:
30 Apr 2021, 15:21
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.
Also some good idea. Currently I would not like to spend the timing digging through it in details. Especially it does not give me the properties I really want to get.

With these step down converters I have no experience, they look as if they might do the job. But they are not adjustable by a microcontroller to control the motor speed this way - in case you might consider those for some setup. But at least those could demonstrate the effect when you e. g. apply 12 V to the input and then have a motor on a constant load driven with 9 V and 6 V. Just measure the current draw from the supply in both cases. The higher the difference between input and output voltage gets, the less current the contraption draws from the supply. Just a buck converter a motor and a supply. And then do it with one of your L293D drivers PWMed. But please first fix the ENABLE-issue to get reliable results.

I would be glad to receive some observations from you how the motor works when the L293D is controlled the "right" way. (I need to be cautious to not annoy MoG by using these terms)

Cordiais cumprimentos
H.A.R.R.Y.

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 18:00
von MasterOfGizmo
rubem hat geschrieben:
27 Apr 2021, 02:05
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.
Why is that a crude solution? Have you seen "int" pins on I²C devices? These are interrupt lines and these are pretty common for exactly this reverse notification. But you shouldn't just send a pulse as this always has a chance if being missed. Instead set the line active whenever you have to report something back and clear it when this report has been sent (e.g. the appropriate register is being read by the master).

This is a very common approach to solve this. And if you make your INT line active low and use an open collector output then you can even chain multiple client devices to this single line. In a case of an event you then just have to poll all possible interrupt sources via i2c to figure out which ones want your attention.

Regarding the problem to stop a motor at a given position: You don't need a PID. Instead you can just slow down shortly before you reach the desired position. This can nicely be observed with current Lego motors as they have a means to adjust exactly this behavior. But this is very load dependent and may not be needed at all. That's why Logo makes this adjustable. See the deceleration profile setting in section 3.27.4 of https://lego.github.io/lego-ble-wireles ... -0x01-0x3f

The ftDuino's manual also has a section about braking an encoder motor:
https://harbaum.github.io/ftduino/www/m ... e.html#6.9

It shows that braking the motor by shortening its inputs makes it stop within 5 pulses which is 1/13 revolution. And this is with no load at all. With an additional mechanical load it will stop even faster. So I see little need to brake beforehand. For precise positioning you'd probably use a stepper motor anyway as the single encoder fischertechnik motors are barely usable for precise repeated positioning. I think Dirk once made a plotter with them and I am sure keeping the precise position was one of the biggest hurdle because of these extremely simple encoders.

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 18:06
von MasterOfGizmo
H.A.R.R.Y. hat geschrieben:
30 Apr 2021, 17:26
MasterOfGizmo hat geschrieben:
30 Apr 2021, 16:04
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.
Nope, Sir, it is not.
I don't understand this reply. What "is not"? There is no energy in those coils?

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 18:13
von H.A.R.R.Y.
Hello MasterOfGizmo,
MasterOfGizmo hat geschrieben:
30 Apr 2021, 18:00
This is a very common approach to solve this. And if you make your INT line active low and use an open collector output then you can even chain multiple client devices to this single line. In a case of an event you then just have to poll all possible interrupt sources via i2c to figure out which ones want your attention.
There is no need to poll. There is a special frame the master sends to the I²C bus (I think it is called INTACK somewhere in the I²C specification) and the devices asserting the interrupt then respond with their address AFAIR. The scheme also allows for priority arbitration among the interrupot sources and the master repeats this INTACK until the /IRQ line is released. /IRQ by this spec is already defined to be an active-low open collector driver.
MasterOfGizmo hat geschrieben:
30 Apr 2021, 18:06
don't understand this reply. What "is not"? There is no energy in those coils?
May you please want to read the complete post and then come back with (a) dedicated question(s)?

Regards
H.A.R.R.Y.

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 18:24
von MasterOfGizmo
H.A.R.R.Y. hat geschrieben:
30 Apr 2021, 18:13
There is no need to poll. There is a special frame ...
Sounds cool. Can you give Rubem (and me) some details how to use that with the Micro:Bit?
H.A.R.R.Y. hat geschrieben:
30 Apr 2021, 18:13
May you please want to read the complete post and then come back with (a) dedicated question(s)?
You replied "it is not" to my statement. And I didn't understand what part of my statement you were referring to. This was unrelated to anything written later. The question is: What "is not"? I still don't understand your reply.

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 18:38
von H.A.R.R.Y.
Hello MasterOfGizmo,
MasterOfGizmo hat geschrieben:
30 Apr 2021, 18:24
You replied "it is not" to my statement. And I didn't understand what part of my statement you were referring to. This was unrelated to anything written later. The question is: What "is not"? I still don't understand your reply.
Okay, my reply mostly goes to "the motor is an inductor". There is some energy stored in the windings, but please consider how the commutator shorts out those while the thing rotates (it is a make-before-break kind of switch). And the large series resistance makes it more a kind of resistor with elevated inductive property. It is definitely nothing like an inductor used in a switchmode-supply or a DC/DC-buck-converter to store magnetic energy. The energy kicking back when the magnetic field breaks down is more or less some side effect of the windings.

Regards
H.A.R.R.Y.

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 21:10
von MasterOfGizmo
I said "a motor is an inductor" and you say "no it's not". The datasheet you linked to says
"the inductive nature of the motor ...". No problem, I can live with that.

Now I'd really like to know what you meant when you wrote that Rubem and me can check the i2c interrupt source on the MicroBit (or an Arduino) without polling. Can you explain that, please?

Re: DIY I²C motor driver with Arduino

Verfasst: 30 Apr 2021, 22:41
von rubem
Hi H.A.R.R.Y and MoG,
That is okay for me. But please do not assume I will work on this particular project with highest priority. I have some other stuff that I want to play around with.
Of course. In fact, don't we all? ;)
With these step down converters I have no experience, they look as if they might do the job. But they are not adjustable by a microcontroller to control the motor speed this way
I was planning to use them only to convert 9V to 5V inside the modules and thus avoid the low performance and heat of a 7805.
I would be glad to receive some observations from you how the motor works when the L293D is controlled the "right" way
Sure, I'll report it back here when I do it.
MasterOfGizmo hat geschrieben:
30 Apr 2021, 18:00
Why is that a crude solution?
Okay, maybe my assessment is not correct, I thought there would be some solution without an extra wire.
Instead set the line active whenever you have to report something back and clear it when this report has been sent (e.g. the appropriate register is being read by the master). This is a very common approach to solve this. And if you make your INT line active low and use an open collector output then you can even chain multiple client devices to this single line.
Interesting idea.
H.A.R.R.Y. hat geschrieben:
30 Apr 2021, 18:13
There is no need to poll. There is a special frame the master sends to the I²C bus (I think it is called INTACK somewhere in the I²C specification) and the devices asserting the interrupt then respond with their address AFAIR.
Thanks for the info. In any case I'll be working with the motor drivers first, the I²C part comes after that.
Regarding the problem to stop a motor at a given position: ... So I see little need to brake beforehand.
This is good to know. Maybe what I was assuming to be a problem (overshooting) will not be so important at the end of the day, especially if the number of pulses is low and more or less the same every time. I should build one of the standard models from the Automation Robots set with the TXT and then replace it with my setup, then comapre them and see if I'll achieve similar results.

Thank you all for the tips so far.

Peace,

Rubem

Re: DIY I²C motor driver with Arduino

Verfasst: 01 Mai 2021, 09:24
von H.A.R.R.Y.
Hello,
MasterOfGizmo hat geschrieben:
30 Apr 2021, 21:10
I said "a motor is an inductor" and you say "no it's not". The datasheet you linked to says
"the inductive nature of the motor ...". No problem, I can live with that.
"inductive nature" I fully agree and this is what I meant when writing "resistor with elevated inductive property". We all agree that any motor is an inductive load and shall be treated as such. Your term "inductor" implies - at least to me - such an energy storage coil with least possible resistance targeted to switched power supply applications. Could you also agree that a motor is not usefull as an energy storing device in this manner?
MasterOfGizmo hat geschrieben:
30 Apr 2021, 21:10
Now I'd really like to know what you meant when you wrote that Rubem and me can check the i2c interrupt source on the MicroBit (or an Arduino) without polling. Can you explain that, please?
I am sorry, I must have mixed this topic up with the SMBus specification (A.2 SMBAlert#). You are totally right, you need to poll for the source of the /INT-line with plain I²C until you deal with the general call scheme depicted in I²C-spec chapter 3.1.13.
But honestly, as long as you are just not interferring with the address of any device that is (getting) attached to your I²C sytem, you are free to implement such a SMBus-like SMBAlert#-scheme to your own I²C contraptions by assigning an INTACK address and have your own devices respond to it appropriately.
rubem hat geschrieben:
30 Apr 2021, 22:41
I was planning to use them only to convert 9V to 5V inside the modules and thus avoid the low performance and heat of a 7805.
Perfect.

Regards
H.A.R.R.Y.

Re: DIY I²C motor driver with Arduino

Verfasst: 01 Mai 2021, 18:45
von juh
Hi there,

quite a wall of text this thread has become! I'll add a couple of lines myself:
rubem hat geschrieben:
28 Apr 2021, 21:32
I don't know anything about these chips, won't the connection to this additional pin also imply an extra wire?
Yes, exactly. It's the approach MoG and Harry have elaborated on since then. I still favour it for this kind of project, and see it more as an option, because, depending on the application, in many cases it will not be a big problem (and much easier to implement) to have the master polling for the result.
rubem hat geschrieben:
28 Apr 2021, 21:32
Now I'm intrigued! But even with the same IDE, I fear ESPs are more complex. ... Which hardware should I use, exactly? And... would you be willing to share your code?
Yes, they are of course much more complex, but mainly if you want to use their advanced features like WiFi, BT, a second I2C port, mulitasking or both cores etc. In the beginning, however, you can use them pretty much like an Arduino, just never forget that they are strictly 3,3V (even if many boards have a 5V pin sourced from the USB, and some say the inputs are 5V tolerant) and that you have to pay attention to avoid some of the pins which might behave unexpectedly at boot time or are input only. But like always, there's plenty of info and at least one library for almost anything out there to help get you started.

Hardwarewise, I guess it doesn't make much of a difference. If in doubt, I'd choose a common, well documented module. The OLED thing I' using ATM, is a bad example, I couldn't find a schematic up to now (and the OLED is in a dumb place for putting the thing in a housing). For this project, I plan on using a DevKitC type form factor, as it has all usable pins broken out, is breadboard ready, and the size would fit in a 30mm ft-compatible wide housing. I'm waiting for delivery of these two variants. IIRC MoG is using the type DevKitC type, also, for the ftDuino32.

And yes, of course I'll share my code, when and if it will ever be finished. However, I'm not sure if one should wait for it. For one, I cannot foretell how fast I'll advance, and secondly, from the bottom of my heart I loathe c++ or anything else that looks even remotely similar. I (self) learned object oriented programming in Oberon-2 many years ago, which was an intellectual pleasure. Object orientation a la c++ and all the other deficiencies of that mess of a programming language make my teeth hurt. So much of my programming, I fear, is copy and paste with too little real understanding of that language.
rubem hat geschrieben:
28 Apr 2021, 21:32
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...
Thank you! See below for my recent test results, no shielding necessary up to now. I wouldn't know about longer distances, though, I guess putting the controller close to the encoder(s) will be a good choice in any case.
rubem hat geschrieben:
30 Apr 2021, 15:21
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)?
Yes, your module approach is similar to what I had in mind with the WeFish project, yet less limited due to the small WeFish form factor. Interest in this project has unfortunately, but understandably, been very low, so my efforts to get this further documented and published are sleeping, yet not dead, at the moment. Originally, I revisited this current encoder project because I was planning for an WeFish quad encoder module. However, in this case, I feel wrapping encoder, drivers, and PID controller in one makes more sense than an I2C encoder-only module.
H.A.R.R.Y. hat geschrieben:
29 Apr 2021, 19:01
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).
Yes, you are right, an Arduino could theoretically be up to the task, in particular if one looks what others have accomplished with an ATtiny2313 (see my link earlier in the thread), for which they had to use Assembler, of course. So it'll depend on one's design goals, personal skill set, and other preferences. Personally I feel more comfortable with having the extra resources and possibilities of ESPs.
rubem hat geschrieben:
30 Apr 2021, 15:21
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.
Well, and I'd recommend just the same. :-) Section 7.3.2, particularly Table 2, of the datasheet has all the info needed on PWMing the driver. I fear my knowledge doesn't go much further than that, Harry and MoG are obviously much more qualified for the details. I see that I'll have to revisit the question of PWM frequency and when to use fast and slow decay, too, when I'll switch to that driver, as planned.
MasterOfGizmo hat geschrieben:
30 Apr 2021, 18:00
Regarding the problem to stop a motor at a given position: You don't need a PID. Instead you can just slow down shortly before you reach the desired position. [...] With an additional mechanical load it will stop even faster. So I see little need to brake beforehand. For precise positioning you'd probably use a stepper motor anyway as the single encoder fischertechnik motors are barely usable for precise repeated positioning.
Hmmm, I'm wondering about the additional load thing. I understand why it would stop faster,if additional load means more friction. But I expect more often than not it will mean more inertia, making the motor stop slower, not faster, particularly for geared motors. Also, I'd expect that an immediate stop will put a lot of strain particularly on a gear drive's gears, that's why intuitively I'd prefer a controlled break. And when I say PID I mean any sensible variation of P, I, and D. What you describe doesn't sound much different from a P-controller. I'll need PIDs in any case to provide a constant-speed mode, but I guess I should make them optional for run-to-position modes.

Concerning precision, see below for my quad encoder results.

A couple of other things before that:

1. Step-down converters

I love these little modules and have already used the type you showed, rubem. However, I'd never trust their max. power ratings, ripple can be a problem in some applications, and I learned that in low current demands a modern regulator need not be less efficient.

2. End stops

The Arduino based Gerber type CNC shields share one input pin for both end switches in one dimension, because given the direction of movement it will always be clear which one of the two it is. That's why I initially planned for the same approach. This thread made me rethink, however, because of course, there is one situation where it will be important to be able to tell the two apart, and that is if a motor is in the parked position, i.e. triggering one end switch, at boot time. The controller will need to know which of the two it is in that situation to prevent possible damage. So I changed my plans, but to save the four extra pins I would need, I'll still share them on one pin, but use a voltage divider on one of them and analogRead() to tell the two apart.

Concerning my current tests, I switched the hall sensor for counting revolutions with an angular hall sensor, the diametrically magnetized magnet is attached directly to the gearbox output shaft, it's mostly hidden by the red heat shrinked tubing I used to fix it. As opposed to my earlier tests, I used the I2C interface to make use of the sensor's full 12bit angular resolution and to avoid using the ESP32's non-linear ADC, so I assume it's measurements are quite exact. I ran a number of unidirectional and bidiractional tests, among them a "random walk" of forward and backward movements of random durations and speeds to see if the encoder position counter would wander off.

web_DSC_3760v.JPG
web_DSC_3760v.JPG (92.36 KiB) 490 mal betrachtet

These are some results from the start and after >1 million encoder steps, the important column is "diff" showing the difference between angular position (12 bit 0-4095, absolute) and encoder position (1561.703 steps per revolution, incremental, null position synched with angular position 0) in percent:

Code: Alles auswählen

  diff=-0.0052 angHere=3922 encHere=35861 angHereF=0.96 encHereF=0.96
  diff=-0.0045 angHere=2018 encHere=50751 angHereF=0.49 encHereF=0.50
  diff=-0.0062 angHere=708 encHere=56501 angHereF=0.17 encHereF=0.18
  diff=-0.0031 angHere=2591 encHere=68146 angHereF=0.63 encHereF=0.64
  diff=-0.0041 angHere=3286 encHere=87153 angHereF=0.80 encHereF=0.81
...
  diff=-0.0024 angHere=1573 encHere=1270268 angHereF=0.38 encHereF=0.39
  diff=-0.0080 angHere=81 encHere=1285325 angHereF=0.02 encHereF=0.03
  diff=-0.0063 angHere=3411 encHere=1291277 angHereF=0.83 encHereF=0.84
  diff=-0.0056 angHere=2483 encHere=1297169 angHereF=0.61 encHereF=0.61
  diff=-0.0002 angHere=3030 encHere=1292684 angHereF=0.74 encHereF=0.74
  diff=-0.0024 angHere=395 encHere=1290121 angHereF=0.10 encHereF=0.10
As you can see, the average deviation is ca. 0.5% and remains the same after >1 million encoder steps. 0.5% is 1.8 degrees, which is the usual resolution of stepper motors (without microstepping), so that assuming we can stop reliably at the desired position (with or without PIDs), this setup will result in stepper motor like accuracy. Enough proof of concept for me to continue with the current approach.

@rubem: I don't want to hijack your thread but as the projects are closely related, I hope it's ok if I share my progress here.

Best,
Jan

Re: DIY I²C motor driver with Arduino

Verfasst: 03 Mai 2021, 15:24
von rubem
Hi Juh,

Yes, this thread has grown a lot. Here are some quick points, with no quotes in an effort to make the text a bit shorter ;)

Thanks for the WeFish link, I probably looked for "we fish" (with a space) and got nothing. It's good you're going back to the encoder project, I don't see any problems in mixing several I²C modules in the same system. For my part, I'll be sticking to the Arduinos now, but in the future I might want to copy your ESP32 module for quad encoders and precision positioning too. It all boils down to a common I²C set of commands and addresses, we could all work on a common specification.

An ESP32 module also looks like a great alternative to the master controller, I could use one instead of the micro:bit in the future. Again, my plans are for separate, discrete, inexpensive hardware modules that contain their own processing and communicate via a common I²C bus to a master controller. The goal is to simplify things as much as possible for fischertechnik hobbyists.

As for the thread itself, no "hijacking" possible because it's not "my" thread, the thread belongs to everyone! Of course anyone who is working on hardware modules is welcome to share their progress here.

Best regards to all,

Rubem

Re: DIY I²C motor driver with Arduino

Verfasst: 04 Mai 2021, 01:54
von rubem
Hi everyone,

I've just uploaded a Fritzing file with the current version of my test setup (i.e. still with the L293D):

Fritzing_2021-05-03_20-43-02.png
Fritzing_2021-05-03_20-43-02.png (193.08 KiB) 360 mal betrachtet

And the schematic:

Fritzing_2021-05-03_20-42-44.png
Fritzing_2021-05-03_20-42-44.png (78.25 KiB) 360 mal betrachtet

I found some discrepancies with the names I gave to the pin numbers, sao I've corrected them in the Fritzing file. I still have to go back to the code and check them again.

The URL is: https://github.com/leosdad/fischertechnik-modules

Best,

Re: DIY I²C motor driver with Arduino

Verfasst: 07 Mai 2021, 16:24
von rubem
Hi all,

To @Juh: I just received an email advertising the board below, looks interesting. It's an Stm32f103c8t6 Arm Stm32, Arduino IDE-compatible and readily available at a very low price. It's a bit on the large side at 53 x 22 mm, but has some intersting specs for the price. It says it runs at 72 MHz but it has a very conspicuous 8 MHz crystal.

chrome_2021-05-07_11-13-57.jpg
chrome_2021-05-07_11-13-57.jpg (63.27 KiB) 258 mal betrachtet

The email links to this article in case you want to exercise your Portuguese skills :D

A quick note: The first tests with the DRV8833 board were encouraging. Fast brake, good torque at low speeds... Until it stopped functioning. All of a sudden nothing moves anymore. I'm not sure if it's the nSleep pin (but I didn't really change anything) or the board was fried, I'll check it out this weekend...

Cheers,

Rubem

Re: DIY I²C motor driver with Arduino

Verfasst: 07 Mai 2021, 18:46
von juh
Yes, rubem, and most importantly these boards also have hardware quadrature encoders. IIRC there are even versions which are pin compatible to Arduino Nanos.

It's hard to keep an overview over all the possibilities, hard- and softwarewise. But our ressources are limited, so I often stick to what I know, well knowing that there might be better options out there. I plan on using WiFi and maybe BT as an alternative control mode in addition or as an alternative to I2C, that's why I'll stick to the ESP32 for the moment, but the Stm32 might be a very good alternative if it's I2C only what you want.

Sorry to hear about your DRV8833. As far as I can reconstruct the circuitry of these little no name boards, nSleep must either be pulled high by connecting the soldering bridge on its backside, or by controlling it explicitly with an additional output pin. It's funny BTW to note that a person used to reading from right to left apparently has shortened the pin labels to EEP for SLEEP and ULT for FAULT... :)

I'll probably use the same PCBs and decided to run them in parallel mode to double their power (cf. datasheet 8.2), just to be on the safe side. For that it is important to note that the pin assignment is different from the chips pinout: IN1=AIN1, IN2=AIN2, IN3=BIN1, IN4=BIN2 and OUT1=AOUT1, OUT2=AOUT2, OUT3=BOUT1, OUT4=BOUT2).

Best
Jan

Re: DIY I²C motor driver with Arduino

Verfasst: 07 Mai 2021, 22:11
von rubem
juh hat geschrieben:
07 Mai 2021, 18:46
Sorry to hear about your DRV8833
Hahaha, it's indeed kaput :( I just tried another one and it works fine, so the first DRV8833 module died on me. I must have shorted some pin while breadboarding, I can't say.

Greetings,

Rubem

Re: DIY I²C motor driver with Arduino

Verfasst: 07 Mai 2021, 22:22
von rubem
juh hat geschrieben:
07 Mai 2021, 18:46
As far as I can reconstruct the circuitry of these little no name boards, nSleep must either be pulled high by connecting the soldering bridge on its backside, or by controlling it explicitly with an additional output pin.
Yes, nSLEEP is connected to VCC via a 47 kΩ resistor by default, to control sleep mode you have to cut the trace. Here's the board schematic.
It's funny BTW to note that a person used to reading from right to left apparently has shortened the pin labels to EEP for SLEEP and ULT for FAULT... :)
Yes, it seems space was too tight for more characters and they left the first ones out... :D

Rubem

Re: DIY I²C motor driver with Arduino

Verfasst: 09 Mai 2021, 02:02
von H.A.R.R.Y.
Olá rubem,
rubem hat geschrieben:
07 Mai 2021, 22:11
it's indeed kaput
This is really not nice to 'hear'. Could you eventually consider to give some schematic of your DRV8833 setup, please?
And maybe this time you could give some higher resolution? Your L293D setup I just can barely read and it was the Fritzing sketch to give some better insight.

Cordiais cumprimentos
H.A.R.R.Y.

Re: DIY I²C motor driver with Arduino

Verfasst: 09 Mai 2021, 17:42
von rubem
Hi H.A.R.R.Y,

The Fritzing files are available in my GitHub project:

https://github.com/leosdad/fischertechn ... n/fritzing

Coincidentally, I've pushed the DRV8833 schematics yesterday. Here are the images, GitHub shows them very nicely:

https://github.com/leosdad/fischertechn ... ain/images

I agree, the schematics above are unreadable. <off-topic>I suspect the forum shrinks files above a certain size. For some unknown reason it does not accept WEBPs (way smaller than PNGs) or SVGs (vector format). (Sorry, pressed Submit instead of Preview again...)</off-topic>

Greetings,

Rubem

Re: DIY I²C motor driver with Arduino

Verfasst: 09 Mai 2021, 17:53
von rubem
Hi again,

Some quick notes about the 8833 diagram:
  • I suspect I'll have to swap D9 and D11 so that D11 connects to the DRV8833's IN1. Reason is that D9 and D10 seem to work together for servos. I didn't test the servos yet.
  • I still plan to add some protection diodes and/or resistors to the inputs.
Best,

Rubem