I suspect it is about the middle of the night where you are. Here's a plan... find a motor with an encoder that is similar to yours... don't buy it. At the end of your paper in the discussion section simply say after doing blah, blah blah, you came to the conclusion that you needed a motor with an encoder. Talk a little about how the encoder works, put it into a simulation and call it quits.
But before you do, try everything you can think of and put that in the discussion before the encoder discussion.
That's the meat of your paper... that get's you done by Sunday. Write as you go... don't leave it all till the end.
You don't have to want to fake leukemia to buy yourself extra time... because that's about what it would take:)
thanks rjo, and yes the gyro/accelerometer have some noise and that's why i use a complementary filter to eliminate all the noise and it work good. this photo represent my Simulink work .and yes i tried a lot of things like putting a different masses on the top of the pendulum to see how it will effect on the stability , and i come out with conclusion that the more the mass on the top of the pendulum is heavier the more the pendulum is more stable. but without an encoders it still vibrates a lot and can't maintain stability
I don't have time to really look at it, but that sure looks like it is spot on. I'm glad I'm not in your class, you are going to mess up the curve for everyone else:)
(in the U.S. frequently we let the best student define what represents and A... everyone else gets either the same or a lower grade).... keep writing. The more you have in your methods section, the better.
I still think power issues can be causing a problem.
The main thing encoders would help with is speed regulation. Having encoders on a wheel allows the microcontroller to adjust the power to motors to maintain the desired speed.
In my experience encoders are needed more on under powered robots than robots which have lots of power. The amount of power required to get a motor to start to move can be much more than to maintain the motor's movement. Your balancing bot is going to spend a lot of its time with the motors just starting to move.
Encoders are a great way of controlling the speed of the motors but there are tricks one can do to motors without encoders to better control the speed.
One of these speed control tricks is using a pulse/brake strategy rather than pulse/coast. By setting the enable pins of the L298N high the power (and hopefully speed) can be controlled by pulsing the direction pin. This will likely require a change in the motor control code you're using.
Pulse/brake control is not as efficient as pulse/coast but the speed control is supposed to much better using pulse/brake.
I have a Mecanum wheeled robot which uses encoders. The robot is a bit under powered for the wheels I'm using and robot was very difficult to control without encoder feedback. The difference between static friction and dynamic friction was a big source of my control trouble. As I mentioned previously, the motors required a lot of power to begin to move but once they were moving the power had to be greatly reduced.
Fellow forum member Rich (aka W9GFO) also has a Mecanum wheeled robot. Rich used more powerful motors than the ones I used and his robot didn't have the same low speed issues my robot had. Rich didn't use encoders on his robot and as you can see (by following the link) it worked great.
If you could provide more power to your motors, I think you will likely increase your ability to control the speed of the robot.
The easiest ways to increase the power of your motors is to increase the battery voltage and to use good wires for your power distribution. I think a 12V battery would likely work better than your 8V (2 cell) battery. If you happen to have two of your 2 cell LiPo batteries, you could connect them in series and produce 16V. I think your current hardware could handle 16V power source. Just make sure you use better wires.
I'm concerned you'll be disappointed in your ability to control speed using homemade encoders. If you have to add encoders to the wheel, the encoders will likely be very low resolution. The encoder examples I posted earlier had 8 sets of black and white stripes on the wheel. 8 stripes will provide 32 transitions when using two sensors. I think you'll have a very difficult time trying to calculate speed with so few transition. Your robot will likely be making lots of very small movements. The wheel will need to move at lest 11.5 degrees before the speed of the wheel can be calculated. I'd think a lot of the required movements would be less than 11.5 degrees so the microcontroller would likely not have an accurate speed reading most of the time spent balancing.
I don't think low resolution encoders are going to be very useful in this application.
BTW it's possible to balance without encoders, if you don't care about drifting around, or returning to a fixed spot, which is much of what encoders bring to the party. I made a simple balancing bot using nothing but a Sharp IR sensor, and others have done the same using just a PING ultrasonic sensor.
well your words are really helpful and i really thank you Duane Degn but i tried to work with different values of voltage but nothing new the same results, i tried with even 16v but it still vibrate a lot
Hi
I've just noticed from your photos that the motors are connected with a wire wrapped- (loosely), around the motor terminals. This is asking for trouble- if you do nothing else SOLDER THEM ASAP! (if you havent already).
Question to forum- should there be suppression from motor to ground??
Do you know what the latency (delay) between the PC and the microcontroller?
While I'd be surprised if the power supply was the main problem you're having, I still think it could be an issue. Those bench top supplies don't work well with motors. I've had robot projects which work fine when powered by batteries but they behave awful when I try to power them from a bench supply.
Again, I doubt this is your main issue but it's still something to think about.
Are there P.I.D. parameters you can tune?
I don't know enough about Simulink to comment on that aspect of the project.
yes the delay is 30 ms .
and no i have no regulation in my system (no PID) i simply can't find where to put it , the robot is commanded by a direct signal from the sensor after being filtered
yes the delay is 30 ms .
and no i have no regulation in my system (no PID) i simply can't find where to put it , the robot is commanded by a direct signal from the sensor after being filtered
30ms should be plenty fast enough but if the control algorithm is just telling the motors to full power whenever it's off center, there's not much hope of having the robot balance smoothly. You need to command the motors a proportional ("P") amount based on the sensor data. You will likely need to keep track of error over time and add a integral ("I") component to your algorithm.
I've personally never needed to include a differential ("D") component to my control algorithms but then my bots haven't needed to balance.
i know that i need a PI regulator but i didn't really know where to put it any suggestions??
When you receive the sensor data you'll want to compare the actual position of the robot with the desired position. The difference between the desired position (let's call it "targetPosition") and the actual position (let's call it "currentPosition") is the error ("error").
You'll want make the output power proportional to this error.
error = targetPosition - currentPosition
power = proportionalConstant * error
The value of the proportionalConstant will need to be figured out with a bit of trial and error.
They used the variable name "setpoint" instead of "targetPosition" and "measured_value" instead of "currentPosition". What I called "power" they call "output".
"dt" is the time interval of your control loop. I think a control loop period of 20ms (50Hz) is fast enough for many robot tasks. I'd think a 30ms control loop would likely be okay. Again, I haven't made a balancing bot so I'm not sure 20ms (or 30ms) is fast enough. Erco is likely to have a better idea of what sort of control periods are acceptable for this sort of robot.
As I mentioned earlier, if you're not proportionally controlling the power/speed of the motor based on the sensor readings, I don't see how you'll keep the robot from oscillating.
well Duane Degn i don't want to be impolite or anything but i already know that one of my problems is that i'm controlling the robot in an open loop and i couldn't find how to controle it in the closed loop and to controle it in a closed loop i need the output of the motor to have a closed loop
i need the output of the motor to have a closed loop
Not really. You can (kind of/mostly) close the loop with your sensors.
I'm pretty sure Erco's balance bot didn't use encoders but it balances great (at least his second one does). He used a distance sensor to determine how far from level he was but your accelerator/gyro should be able to do something similar.
I had seen the second video he posted but I just watched the first one and I can see he's balancing his bot with just the CR servos in a BOE-Bot. Very cool!
It looks like the bot in the second video he posted also used CR servos. This bot's servos were bigger than the ones included with a BOE-Bot. He makes this stuff look easy.
In the second video Erco mentions using a PID algorithm. A PID algorithm can certainly be used without encoders.
ahmed7 I am guessing that English might be your third or fourth favorite language... so you are two or three languages ahead of most of us:)
Language differences are getting in the way here of good communications. Let me talk about the miscommunication a little.
well your words are really helpful and i really thank you Duane Degn but i tried to work with different values of voltage but nothing new the same results, i tried with even 16v but it still vibrate a lot
As I understand it one of the things Duane is saying that the motors may not be getting all of the current you are trying to send them, because the wires that you are using are too thin... they will heat up, heat causes resistance, resistance lowers current.
The other thing that Duane was saying is that to use the battery correctly you need to know peak and sustained currents. I don't know enough about the type of battery you are using to have an opinion, but Duane, Erco and several others here do... if there is a consensus that you are using the wrong battery or not enough of the right batteries... you can take it to the bank. Don't think about it, just do it and see who is right:) You might need to add a battery or two in parallel to be certain that your motors are always getting what they need and what you think.
well Duane Degn i don't want to be impolite or anything but i already know that one of my problems is that i'm controlling the robot in an open loop and i couldn't find how to controle it in the closed loop and to controle it in a closed loop i need the output of the motor to have a closed loop
That is exactly what Duane is trying to explain.
logic is what closes the loop.
you have a desired angle(the goal you are trying to achieve), you measure the actual angle with your sensors, you want to get closer to the desired angle. To do this you apply power to the wheels... how much power? Who knows exactly?... that's an issue for physics, this is engineering. What you do know is that the closer you get to the desired angle... the less power you are going to apply... until you reach an almost steady state of applying the smallest amounts of power to keep the bot stable and upright. Somebody figured out that you can replace a lot of complicated logic, by reducing a problem like this to a simple proportionality.
All you know is that the farther your measured angle is from the desired angle the more power you want to apply. But how much is the issue... you just know that you want it to be "proportional"... you are using highly linear thinking.
If you want an initial estimate of what your proportionality constant should be, you can use basic formulas to get the starting point, but you don't have to. You can incrementally change the proportionality constant until you find the one that works best for your bot... and you can use logic to reduce the number of trials that you have to use to get to that proportionality constant's best value... pretty neat stuff to put into your brain and keep there.
There is no law that says you have to do it this way... and in fact for some problems, this kind of thinking doesn't get you exactly where you want to be... but for this problem... your problem, it is very powerful and is probably why you are having problems.
So, let's stay on this point for a while... your bot might have several problems, this one is the most critical.
Brush DC motors are notorious for inducing noise into electronics.
So how come one of the geniuses in this forum hasn't figured out how to signal condition the bejeesus out of that noise to create a virtual motor encoder. The brushes & armature are making regular current spikes, directly proportional to motor RPM. The info is there in the noise, just need to read it. We've been trying to suppress it all these years, but I say it's high time to embrace it. As we say in the toy business, if you can't fix it, feature it.
That's precisely how this SoundRacer works, it derives the engine RPM by analyzing noise in the 12V supply. http://www.soundracer.se/?p=98 I heard they even patented it.
PhiPi, my good man, please see to it! Or will someone else rise to the challenge? Is there a patent in your future?
You must get the basic things right before looking for exotic solutions-
good power supply
large enough conductors
good SOLDERED joints
eliminate motor noise (capacitor from each motor terminal to earth- maybe one across motor terminals)
plenty of unobstructed desk space
Comments
I suspect it is about the middle of the night where you are. Here's a plan... find a motor with an encoder that is similar to yours... don't buy it. At the end of your paper in the discussion section simply say after doing blah, blah blah, you came to the conclusion that you needed a motor with an encoder. Talk a little about how the encoder works, put it into a simulation and call it quits.
But before you do, try everything you can think of and put that in the discussion before the encoder discussion.
That's the meat of your paper... that get's you done by Sunday. Write as you go... don't leave it all till the end.
You don't have to want to fake leukemia to buy yourself extra time... because that's about what it would take:)
Good luck.
GO TO BED.
You might have noise coming out of your gyro/accelerometer... can you look at those signals and make graphs for your paper?
(in the U.S. frequently we let the best student define what represents and A... everyone else gets either the same or a lower grade).... keep writing. The more you have in your methods section, the better.
The main thing encoders would help with is speed regulation. Having encoders on a wheel allows the microcontroller to adjust the power to motors to maintain the desired speed.
In my experience encoders are needed more on under powered robots than robots which have lots of power. The amount of power required to get a motor to start to move can be much more than to maintain the motor's movement. Your balancing bot is going to spend a lot of its time with the motors just starting to move.
Encoders are a great way of controlling the speed of the motors but there are tricks one can do to motors without encoders to better control the speed.
One of these speed control tricks is using a pulse/brake strategy rather than pulse/coast. By setting the enable pins of the L298N high the power (and hopefully speed) can be controlled by pulsing the direction pin. This will likely require a change in the motor control code you're using.
Pulse/brake control is not as efficient as pulse/coast but the speed control is supposed to much better using pulse/brake.
I have a Mecanum wheeled robot which uses encoders. The robot is a bit under powered for the wheels I'm using and robot was very difficult to control without encoder feedback. The difference between static friction and dynamic friction was a big source of my control trouble. As I mentioned previously, the motors required a lot of power to begin to move but once they were moving the power had to be greatly reduced.
Fellow forum member Rich (aka W9GFO) also has a Mecanum wheeled robot. Rich used more powerful motors than the ones I used and his robot didn't have the same low speed issues my robot had. Rich didn't use encoders on his robot and as you can see (by following the link) it worked great.
If you could provide more power to your motors, I think you will likely increase your ability to control the speed of the robot.
The easiest ways to increase the power of your motors is to increase the battery voltage and to use good wires for your power distribution. I think a 12V battery would likely work better than your 8V (2 cell) battery. If you happen to have two of your 2 cell LiPo batteries, you could connect them in series and produce 16V. I think your current hardware could handle 16V power source. Just make sure you use better wires.
I don't think low resolution encoders are going to be very useful in this application.
BTW it's possible to balance without encoders, if you don't care about drifting around, or returning to a fixed spot, which is much of what encoders bring to the party. I made a simple balancing bot using nothing but a Sharp IR sensor, and others have done the same using just a PING ultrasonic sensor.
I've just noticed from your photos that the motors are connected with a wire wrapped- (loosely), around the motor terminals. This is asking for trouble- if you do nothing else SOLDER THEM ASAP! (if you havent already).
Question to forum- should there be suppression from motor to ground??
Dave
https://www.pololu.com/docs/0J15/9
While I'd be surprised if the power supply was the main problem you're having, I still think it could be an issue. Those bench top supplies don't work well with motors. I've had robot projects which work fine when powered by batteries but they behave awful when I try to power them from a bench supply.
Again, I doubt this is your main issue but it's still something to think about.
Are there P.I.D. parameters you can tune?
I don't know enough about Simulink to comment on that aspect of the project.
and no i have no regulation in my system (no PID) i simply can't find where to put it , the robot is commanded by a direct signal from the sensor after being filtered
30ms should be plenty fast enough but if the control algorithm is just telling the motors to full power whenever it's off center, there's not much hope of having the robot balance smoothly. You need to command the motors a proportional ("P") amount based on the sensor data. You will likely need to keep track of error over time and add a integral ("I") component to your algorithm.
I've personally never needed to include a differential ("D") component to my control algorithms but then my bots haven't needed to balance.
When you receive the sensor data you'll want to compare the actual position of the robot with the desired position. The difference between the desired position (let's call it "targetPosition") and the actual position (let's call it "currentPosition") is the error ("error").
You'll want make the output power proportional to this error.
The value of the proportionalConstant will need to be figured out with a bit of trial and error.
Here's some pseudo code from the Wikipedia article on the subject.
They used the variable name "setpoint" instead of "targetPosition" and "measured_value" instead of "currentPosition". What I called "power" they call "output".
"dt" is the time interval of your control loop. I think a control loop period of 20ms (50Hz) is fast enough for many robot tasks. I'd think a 30ms control loop would likely be okay. Again, I haven't made a balancing bot so I'm not sure 20ms (or 30ms) is fast enough. Erco is likely to have a better idea of what sort of control periods are acceptable for this sort of robot.
As I mentioned earlier, if you're not proportionally controlling the power/speed of the motor based on the sensor readings, I don't see how you'll keep the robot from oscillating.
Not really. You can (kind of/mostly) close the loop with your sensors.
I'm pretty sure Erco's balance bot didn't use encoders but it balances great (at least his second one does). He used a distance sensor to determine how far from level he was but your accelerator/gyro should be able to do something similar.
I had seen the second video he posted but I just watched the first one and I can see he's balancing his bot with just the CR servos in a BOE-Bot. Very cool!
It looks like the bot in the second video he posted also used CR servos. This bot's servos were bigger than the ones included with a BOE-Bot. He makes this stuff look easy.
In the second video Erco mentions using a PID algorithm. A PID algorithm can certainly be used without encoders.
Language differences are getting in the way here of good communications. Let me talk about the miscommunication a little.
As I understand it one of the things Duane is saying that the motors may not be getting all of the current you are trying to send them, because the wires that you are using are too thin... they will heat up, heat causes resistance, resistance lowers current.
The other thing that Duane was saying is that to use the battery correctly you need to know peak and sustained currents. I don't know enough about the type of battery you are using to have an opinion, but Duane, Erco and several others here do... if there is a consensus that you are using the wrong battery or not enough of the right batteries... you can take it to the bank. Don't think about it, just do it and see who is right:) You might need to add a battery or two in parallel to be certain that your motors are always getting what they need and what you think.
That is exactly what Duane is trying to explain.
logic is what closes the loop.
you have a desired angle(the goal you are trying to achieve), you measure the actual angle with your sensors, you want to get closer to the desired angle. To do this you apply power to the wheels... how much power? Who knows exactly?... that's an issue for physics, this is engineering. What you do know is that the closer you get to the desired angle... the less power you are going to apply... until you reach an almost steady state of applying the smallest amounts of power to keep the bot stable and upright. Somebody figured out that you can replace a lot of complicated logic, by reducing a problem like this to a simple proportionality.
All you know is that the farther your measured angle is from the desired angle the more power you want to apply. But how much is the issue... you just know that you want it to be "proportional"... you are using highly linear thinking.
If you want an initial estimate of what your proportionality constant should be, you can use basic formulas to get the starting point, but you don't have to. You can incrementally change the proportionality constant until you find the one that works best for your bot... and you can use logic to reduce the number of trials that you have to use to get to that proportionality constant's best value... pretty neat stuff to put into your brain and keep there.
There is no law that says you have to do it this way... and in fact for some problems, this kind of thinking doesn't get you exactly where you want to be... but for this problem... your problem, it is very powerful and is probably why you are having problems.
So, let's stay on this point for a while... your bot might have several problems, this one is the most critical.
So how come one of the geniuses in this forum hasn't figured out how to signal condition the bejeesus out of that noise to create a virtual motor encoder. The brushes & armature are making regular current spikes, directly proportional to motor RPM. The info is there in the noise, just need to read it. We've been trying to suppress it all these years, but I say it's high time to embrace it. As we say in the toy business, if you can't fix it, feature it.
That's precisely how this SoundRacer works, it derives the engine RPM by analyzing noise in the 12V supply. http://www.soundracer.se/?p=98 I heard they even patented it.
PhiPi, my good man, please see to it! Or will someone else rise to the challenge? Is there a patent in your future?
good power supply
large enough conductors
good SOLDERED joints
eliminate motor noise (capacitor from each motor terminal to earth- maybe one across motor terminals)
plenty of unobstructed desk space
if it still shows no improvement- let us know
Dave
This is open loop:
If you're driving the motors directly with PWM you might find you need to tune the PWM curve to remove the dead spot in the middle.
Check out this link for Arduino-based balancing robots. The first one is open loop too:
https://www.intorobotics.com/5-best-examples-build-diy-self-balancing-robot/