Notifications
Clear all
Topic starter
2020-01-09 9:43 am
I've finally been working on the motor control circuits of my robots. I've hooked up the encoder feedback for the first time and I've been using Bills motor speed control article here as a guide:
Build a Robot Car with Speed Control
By the way, I've learned about the "digitalPinToInterrupt" feature which works out a lot better than using Interrupt numbers for various reasons. Thanks for that one Bill.
In any case, in addition to speed control I am also interested in acceleration control as well as gaining good low speed control for finer maneuvering capabilities. It's difficult to maneuver precisely when motors need to be turned on and off at high speeds.
However, this presents a problem with cheaper motors like those found on the robot car in the article (the same type of robot car that I am working on). The problem is that these motors don't want to turn on at all until the PWM is up around 150. And even then they weren't dependable as sometimes they simply wouldn't start and I had to use an even higher value. This reduces the amount of control available for actually controlling the speed of the motors. They closer you get to 255 the less room there is for motor speed control.
In any case, what I discovered is that by using a higher voltage on the motors I can actually make them go slower more dependably. The reason has to do with the characteristics of PWM. If you're giving a short pulse of low voltage the motor doesn't want to respond to it. But if you give a short pule with a higher voltage the motor will respond. So ironically the higher voltage you can apply to the motors the slower you can make them go when using PWM. In other words, they will respond better to shorter pulses.
So my next mission is to see how high I can up the voltage using a L298N motor controller and a 6v PM motor. The L298N motor controller can handle up to 46 volts. I won't be going that high so I don't think I'll need to worry about the L298N. A 6v PM motor can usually handle quite a bit more voltage. You could probably even up this to 12 volts, especially if it won't be run wide open. This arrangement should allow for far more control over the motor at very slow speeds (short PWM pulses).
The other thing I'd like to do is rewire the motors using heavier wires between the motors and the controller. This will allow more current to flow easier especially in a PWM mode. And finally, I'm thinking of using shielded motor wires. Instead of worrying about electronic motor noise everywhere else on the robot, I figure I may as well nip it in the bud on the motor wires themselves.
So now I have a lot to do to see if I can improve on this little car robot. I thought I'd post my observations here and see what others think. I haven't actually tried upping the voltage yet, but it seems to me intuitively that this should improve the situation quite a bit. I have 8 of these robots now, so I want to get these motors under control as best that I possibly can. I'm not liking the crude control I currently have. So I'm hoping to be able to improve on this so I can gain a bit more control for fine maneuvering.
And now I'm going to bed @ almost 5:00 AM! I should be getting up!
DroneBot Workshop Robotics Engineer
James
2020-01-09 1:37 pm
I am absolutely no expert here, but when I see problems like this, I think there are better ways to deal with it than manipulating voltage. If you need a greater PWM value to move the motor, then maybe the motor is just too small, or the gear ratio isn't suitable for your specific load?
I've also noticed that a lot of people here barely venture outside of the Auduino UNO, Mega (great for learning and prototyping, indeed), or PI, but there are good reasons (especially for robotics, I think) to go for a different board, such as the Arduino Due! OK, it's run's on 3.3 volts, but so what? the advantages far, far outweigh that minor hiccup, and with those cheap logic level converters you can get these days, it's not a problem at all.
32Bit, 84 MHz processor, ton's more memory and GPIO's, and 12Bit DAC's which can give you a PWM of 0-4095, etc...
To me, this is a winner, especially for this kind of project, and the fastest board I've used to date, and it's not that much more expensive! It's that fast, many hundreds lines of logged text from a large structure appear in the serial monitor even before I can say abracadabra, even at 9600 baud rate!
2020-01-09 3:15 pm
STM32 could probbably also be a good candidate.
I think that for real fine control stepper motors are required.
It would be interesting to see what you come up with.
hj
hj
2020-01-09 3:16 pm
STM32 could probbably also be a good candidate.
I think that for real fine control stepper motors are required.
It would be interesting to see what you come up with.
hj
hj
2020-01-09 3:41 pm
The problem is that these motors don't want to turn on at all until the PWM is up around 150.
Yes I noticed that. For me I just chose three speeds as I didn't see the need for finer speed control than that. I think the L298 drops the power supply by 2 volts? Suggest you measure the voltage on the motors at 255 pwm? I used a 9 volt battery. How fine do you really need to control the speed? Perhaps the L298 circuit is not complex enough if all it does is pulse a fixed voltage supply? I used this motor controller kit on a 24 volt window wiper motors used on my large robot base and found it was able to maintain a fixed torque at very low speeds.
https://www.jaycar.com.au/12-24vdc-20a-motor-speed-controller-kit/p/KC5502
http://archive.siliconchip.com.au/cms/A_112476/article.html
2020-01-09 5:44 pm
I won't be going that high so I don't think I'll need to worry about the L298N.
Keep in mind, since you are raising the voltage, current will also increase. For that reason, you certainly DO need to worry about the L298.
2020-01-09 5:49 pm
I have also found low PMW values do not drive my motors at all, but once started with a suitably large PMW value, the PMW value can be dropped considerably and the motors will still turn. As mentioned by others stepper motors are good for low speed control albeit at the cost of more circuitry. Also I think steppers don't run as fast, use more power, have less torque than normal DC motors, and the faster they run the less torque they have. (this is my impression anyway from dabbling over the past couple of years)
Topic starter
2020-01-09 7:07 pm
STM32 could probbably also be a good candidate.
I actually have 2 STM32 Black Pills onboard the robots. One on each side. See photo below. It's the little board mounted on the side underneath the Mega.
I've added the two STM32s for reading the motor encoders and then controlling the motors via PWM. The STM32 runs at 72Mhz so it will be more likely to catch all the pulses of the motor endoders. Although so far the Mega is reading both motor encoders via IRQs and it's reporting back the correct number of pulses so thus far it's keeping up. The idea behind the STM32 boards is that I'll be able to add more IRQ sensors and have the STM32 boards handle those as well. Then the Mega will only need to send and receive a commands and data from the STM32 boards and be freed up to do other things like processing the results and communication with the laptop computer, (or with the Raspberry Pi on the front of the robot to be used later).
So there will be 4 microcontrollers on this little tiny robot when it's fully up and running. Plus full communication with a laptop computer. For a little tiny car robot it should be pretty darn smart when all is said and done. The RaspPi even has video camera connector, so I'll be able to add a RaspPi camera to this little thing eventually.
In the meantime I don't think a different microcontroller board will make much difference in motor performance as PWM is still PWM no matter which microcontoller is being used.
I think that for real fine control stepper motors are required.
Agreed. That would be ideal. I'm using these little robot cars because I'm cheap. ?
But I better qualify that! I'm currently building 8 of these!
So everything I spend on them needs to be multiplied by 8. Adding $10 to the cost actually results in $80 for the whole project. So this is why cheapness is paramount. ?
I've found a place where I can buy these robot cars for under $6 a piece. That's 6 x 8 = $24 for all 8 robot chassis complete with motors, wheels, and motor encoder disks. So I'm really trying to keep costs down as much as possible. Adding stepper motors to the design could result in a far more expensive robotics experiment. If I had the dough I'd give a go. But I don't have that kind of bread.
Why am I building 8 of these useless toy robot cars? Well, I actually have several reasons. First and foremost I'm the kind of experimenter who likes to have a lot of prototypes to work with so I can try different things on them without having to ruin a previous prototype that I already have up and running. ?
But there is also a second reason, and that is becasue I would like to play around with having these robots working together as a team. As they survey my house floor plan they can compare each other's measurements and do various calculations to better map out the area. It's an experiment in robot coordination.
Currently these things will cost about $50 each to build. (I'll be using Pi Zeros on future models). That's 50 x 8, or $400 for the whole swarm of of 8 robots. I know I'll go over that by quite a bit and end up spending about $100 on each robot. That will be $800 for the bunch. That's bad enough already!
But as you can see, if each robot started to approach a couple hundred bucks a piece that soars the $800 to $1600 and so on.
So this is the reason for my extreme frugality. ?
You might think, "Hey if you're going to invest $800 in robots you should shoot for the best quality possible". The problem with that is that if you start out shooting for the best quality from the get go, then you end up spending $8000 instead of $800.
So I'm kind of financially stuck with having to make these cheap robot cars perform at the best possible performance level as-is. Adding stepper motors, etc, ends up breaking the bank.
DroneBot Workshop Robotics Engineer
James
Topic starter
2020-01-09 7:14 pm
How fine do you really need to control the speed?
It's not that I want to be able to make the robots go slow. The problem arises when trying to position the robot in a very precise position. If the motors can only run fast, then to even tell it to move 1 encoder pulse results in a very jerky motion that overshoots the intended position target. If you could make the motor go slower when making fine adjustments to position you can eliminate the jerky start and stop.
This is also why it won't work to give the motor a full speed kick to get it started and reduce the speed after it's running. You've already ruined the fine positioning by giving the motor the full speed kick.
DroneBot Workshop Robotics Engineer
James
2020-01-09 9:10 pm
This is also why it won't work to give the motor a full speed kick to get it started and reduce the speed after it's running. You've already ruined the fine positioning by giving the motor the full speed kick.
I can get my motors off to a smooth start without giving a full speed kick, just enough to get them turning. But then I'm using a large gearing ratio to enable them to have high torque at low speed. Of course this is at the expense of the ultimate top speed that could be had with a lower gearing ratio. Maybe it's worth considering motors with a higher gearing ratio to the ones you are using.
Topic starter
2020-01-09 10:19 pm
Maybe it's worth considering motors with a higher gearing ratio to the ones you are using.
Perhaps you didn't read my post about keeping the prototyping costs down?
When I go to build a seriously functional robot I'll definitely be using far better and more expensive motors, etc. Besides, it never hurts to learn how to squeak out the best results from inferior systems ?
A second thing I've just noticed today is the extreme problem of the right and left motors turning at different speeds. Bill mentions this in his instructional video. I just noticed it here on the test bench. When I run both motors for say 500 encoder pulses the left motor runs for quite a bit longer than the right motor. This means that the left motor is running slower at the same PWM signals.
There are several ways of correcting for this. One obvious way would be to try to figure out what the difference is and try to adjust the PWM signal to each motor so they both run at the same speed. But that solution isn't really very good, or dependable. A better solution is to break up a 500 encoder-pulse run into something like 10 50-pulse runs in succession. This would cause a correct to the motion every 50 pulses by allowing the slower motor to catch up in smaller increments rather than waiting until the end of the run and just causing the robot to turn to the right after having gone off course.
Motor control is obviously a science in itself.
I haven't yet put any sensors on the robot. Unless you want to consider the encoder feedback from the motors a "sensor". My current goal is to be able to run this robot around the floor programmatically having it be able to repeat a sequence of paths as as closely as possible without any sensory input for correction, save for the motor encoder feedback.
Only after I have gained the best control over the robot in this situation will I be prepared to move on to adding distance sensors.
I think one problem that is often made is that people take a robot has not yet been fully optimized mechanically, and jump right into using sensors to try to correct for everything. The problem with this is that then the distance sensors are so busy trying to correct for a poorly functional robot that it only adds to the confusion when trying to use them for actual navigation.
A good analogy would be like trying to drive a car that is badly out of alignment. If you've ever driven a car that is poorly aligned you'll know what I mean. You need to spend a lot of effort just to keep the thing going in a straight line. That's not something you want to be doing.
So the more accurate this robot can drive itself just via encoder feedback, the far more efficient the distance sensors will be when added.
In other words, if I can make this robot go from my living room to my kitchen and back again just on encoder information without hitting any walls, then when I move up to using distance sensors all I'll need them to do is make very small corrections for a perfect course.
Otherwise, if the bare-bones robot is already way out of whack the distance sensors are going to have their hands full just trying to get the whacky robot to go in straight line. The distance sensors will be spending all their time making corrections for errors that the robot itself is creating.
We certainly don't want that situation.
DroneBot Workshop Robotics Engineer
James
2020-01-09 10:48 pm
Perhaps you didn't read my post about keeping the prototyping costs down?
Well a multiple Jeston Nano man sure would need to nip and tuck elsewhere ? .
When I run both motors for say 500 encoder pulses the left motor runs for quite a bit longer than the right motor.
I found the same with my motors and corrected it with encoder readings as you are doing. You may want to experiment and code all this from scratch for yourself, if so don't follow the link below. I link not to any of my code, but from an example from Sparkfun that I used to get going with this.
1de08ffaca990b65fade81cb8d01a44a
Looking forward to seeing your code when your done!
Topic starter
2020-01-09 11:23 pm
Well a multiple Jeston Nano man sure would need to nip and tuck elsewhere
Exactly. ? I have 2 already and I'm desperately drooling to buy a third one. ? I love them! They are a fantastic little development board. Not to mention that they double as a not-to-shabby desktop computer.
I'll definitely be incorporating a Jetson Nano into any seriously functional robots I end up building.
Looking forward to seeing your code when your done!
I'll post the code when it's finished. Although my code includes a communications interface to my laptop computer via an ESP8266 WiFi module on the Arduino Mega. So the whole shebang might not be useful to others unless they have a similar set up. I could just post a scaled down version of the motor control code itself I suppose.
I'm also using PORTL commands instead of using digitalWrite to individual pins which may seem foreign to many people. Of course I still need to use analogWrite for the PWM. Once I get the whole thing done and running around on the floor the way I want it I'll make a video of it.
DroneBot Workshop Robotics Engineer
James
2020-01-09 11:50 pm
The first thing I did was to get my robot to drive in a straight line both forward and backward using encoder data. Then get it to turn by 90 degrees again using the encoders. Then get it to move in a rectangle to see how well it would return to the starting position. For me a "real" robot will be able to "look around" to determine its position and orientation so using the encoders for navigation seems pointless. Ideally for dead reckoning you need powerful stepper motors for the same reason they are used in 3d printers.
2020-01-09 11:54 pm
I would be interested in the whole shebang. I can always purchase a ESP8266 WiFi module.
Page 1 / 2
Next