Better Touch Better Business
Contact Sales at Hengxiang.
Latest products
upside up - robot balancing revisited
by：HENGXIANG
2020-05-27
This instructable guides you through building a simple two-wheeled balancing robot and takes some time to explore the various factors that affect balance performance.
This is my second robot project and I have two key motivations-identify and improve the factors that limit the balance performance of the first robot and integrate a more integrated Arduino 101 form factor.
If interested, here is a link to the Instructure of my first balancing robot project.
Key components of the robot include Arduino 101 board, Arduino motor control shield, two 12 v gear DC motors with Encoders and Bluetooth modules.
Finally, the cheap battery can make the robot more mobile, and the matching Android application can make the robot tune and control.
Here are some links to more ingredient details: in this project, I have some ideas on how to improve the balance of the robot: Finally, I was able to make significant improvements in balancing performance, I have to say, I\'m a little surprised by which changes provide the biggest improvements!
The robot chassis is designed in layers that are quite common, using ready-made materials
Each layer has inches of plywood attached to the stand for each layer.
The robot assembly starts with the motor layer, using the dimensions shown in the figure.
Using the 1/4-bit and edge boot on the router, cut 8 slots to install the DC motor and control the wire cut 9 slots for the motor.
The size of the last slot allows the motor wire connector to pass through the hole.
The mounting holes are drilled in every corner and the sink head is on the bottom so that the mounting screw head is flush.
Connect the motor to the plywood layer using a hose fixture.
To achieve a flexible but robust electrical connection of the motor, a 90 degree perforated connector was used, fixed to the motor layer with a custom bracket.
The battery layer is similar, but the battery Velcro band has only two slots.
It includes the same corner mounting holes, but two more larger holes are drilled to route the motor wires to the electronic layer.
To avoid inductive noise, the power supply and control lines are wired on separate columns.
The two batteries are zippered together and secured to plywood with Velcro straps found in a local amateur store.
The electronic layer preparation includes drilling the same mounting and wire management holes, as well as mounting holes for the Arduino board complex and power switch modules.
The top layer contains only 4 corner mounting holes.
I finish the chassis by designing a shock absorber for each corner, built in plastic springs and felt pads, designed to soften the impact of the fall.
It turns out that waterfalls are an integral part of the development of balancing robots.
At the last step of the construction, I used RC truck tires on the robot.
I bought one from a local hobby store, but they are similar to online ones. The axle-to-
Wheel adapter design 10-
32 fixing screws that fix the adapter on the motor shaft.
A slot of 10-
32 nuts are included, allowing the wheels to be connected directly, and the metal tap bit is used to add the thread to the fixing screw hole after the adapter is printed. .
Below is the STL file for 3D printed parts.
I use Autodesk Fusion 360 for design, Cura for slicing, and then PLA printing on simple metal in PrintrBot.
The only tricky thing is the bumper, where I need to use 0.
The thickness of the shell is 4mm to obtain the desired results.
3D print: the wiring diagram shows the wiring connection between the electrical subsystems of the robot.
In order to connect the motor to the motor shield, I used 20 gauge stranded lines as the power supply and the CAT 5 solid wire as the encoder connection.
I used orders extensively.
Rear connector and heat shrink for strong but flexible connection.
I chose Keyestudio Motor Shield because it is cheap and has a small prototype area.
Connectors for Bluetooth modules and motors A and B encoders use 4x1 single row connectors.
I also convert the voltage divider from 12 v of the battery to 3.
The Arduino 101 simulates 3 v of the input on the motor shield.
For connections between resistors, connectors and Arduino pins, separate wires in CAT 5 cables are used.
Note: I don\'t know if there is an error making my motherboard or if they should be shipped this way but I have to shorten V-logic to 3.
There are 3 v on the motor shield and pads on the board.
The pads are empty at the time of delivery and this connection is required to make the motor shield work.
The motor shield and Arduino 101 do not match on the pin assignment of PWMB, which is the pulse width modulation control of the motor B.
The shield has this on pin D11, but the Arduino 101 does not support PWM on the D11.
To fix this, I assigned PWMB to D9 in the Arduino 101 sketch and added a jumper to the motor shield between D9 and d11.
As an additional precaution, I clamp the D11 pin on the motor shield to avoid any possible contention between D9 and D11 on Arduino 101.
The power jack input is included so that the robot can operate with a wired power supply.
I used this extensively in early testing because no battery charge is required and the supply voltage is consistent.
Note: I use the 12 V/5A power brick as a power supply when tying, not to charge the battery.
Power bricks or batteries can all be used as power supplies for robots, but never both.
The battery must be charged with a suitable charger.
I split the robot sketch into 4 files, mainly to improve the readability of the code.
The file and the general content is: the code does reference the Arduino. h, CurieIMU.
H and MadgwickAHRS.
So you need to install the necessary libraries for Arduino 101 for compilation.
I\'m not going to go through the code completely because the code comments are quite good, but some general comments will be made: to adjust the control parameters of the robot and monitor the telemetry data in real time, I have developed a companion Android app.
It was developed using MIT App Inventor 2, which has a lot of educational and training information.
The app is a simple collection of buttons and sliders that allow the user to configure and control the robot.
Above is a screenshot of the app-it\'s very self-usedexplanatory.
A few notes: I have included the aia file so that you can open it in the MIT App Inventor environment to further research or modify the Android App.
Now, let\'s talk about how to improve the balance performance of the robot, which is an interesting part.
I have some ideas on where to start looking, but like any system, it\'s hard to know what the cross-dependent variables are.
So, I just jumped in, not too analytical.
The control loop time interval starts by changing the time interval for evaluating the balance PID.
I measured the default Arduino 101 PWM cycle at 2 MS, my previous project used a value of 20 MS, so I started at 5 MS and doubled the interval until the bot could not balance
The robot is able to balance in 5 ms, but it seems to be too active and oscillate in about 120 ms.
It was able to balance again at 10 mS, but the oscillation speed dropped to 280 mS.
The oscillation cycle returns to about 180 MS at 20 MS, but the response seems to be slow rather than active.
At the age of 40, the response became more sluggish, the balance became unstable, and the robot was not always able to maintain balance.
My conclusion is that while the PID evaluation interval is sure to affect the behavior of the robot and it does have to be higher than some of the lowest speeds in order to be able to balance, this is not a magic bullet.
For the rest of my tests, I used the control loop interval of 5 ms.
Then I moved to the sensor fusion filter.
Why do we need a fusion filter?
In order to answer this question, we need to check the core of the balance system-IMU (
Inertial measuring device.
The IMU consists of two types of sensors-the gyro and the accelerometer.
The gyro measures the angular change rate or angular velocity.
In theory, good angle position estimation can be generated by integrating the output of the gyro.
Unfortunately, the gyro sensors have an effect called drift-that is, they record some small speed of light even when they are still.
So if you only generate an estimated angle by integrating the gyro output, you will have an error that will continue to grow over time-this problem makes the only solution for the gyro out of balance.
Enter the accelerometer.
The value reported by the accelerometer will include the effect of gravity, which is constant, and any other acceleration that will vary depending on the movement of the device.
For the IMU, it\'s the gravity vector we\'re interested in.
The idea of fusion filters is to generate an estimated angle by combining these two sensors.
It is conducive to the gyro of instantaneous output (
Through high pass filter)
However, by measuring the gravity direction of the Earth, the accelerometer outputs for a long time (
Through a low pass filter)
Clear any drift.
We need a fusion filter, but which one?
There are very complete and complex solutions.
The Kalman filter is one of the more prominent fusion filters, but even an engineering degree won\'t allow you to fully understand what\'s in the black box.
For this project, I used a similar but less demanding solution, Madgwick filter.
One of the main reasons I use this filter is-it\'s bundled with Arduino 101!
But the configuration of the IMU in equilibrium-with only one degree of freedom, creates constraints that allow us to use the simpler solution, the complementary filter.
Since the multiplication factor of each term adds up to 1, the complementary filter gets its name.
The structure diagram of the complementary filter is shown in Figure 1.
For the details behind the complementary filter, there are some very good ways to deal with it online, so I only provide the final filter equation above.
In the equation, A is the constant that determines the properties of the filter.
In addition, it should be noted that in the accelerometer angle calculation, we use the small angle approximation-for less ~ Angle of 30 °, sin (θ)≈ θ in radians.
For our robot, it will fall down if the angle is close to 30 °, so this assumption seems to be valid.
So we can skip sin (θ)
There is little impact in this calculation.
Finally, the time constant of the complementary filter is also shown in the figure above.
I tested Madgwick and the complementary filter to see how it affects the balance of the robot.
The Beta of the installed stock Madgwick filter is set to 0.
1, use the define statement in MadgwickAHRS. h header file.
The robot will not balance with this setting-the response is a bit too slow.
Played a circle and found that it was set to 0.
01 best balance is enabled, although the setting has some compromise on absolute angle accuracy.
If you keep the robot at an angle, say 20 °, and then restore it to its upright position, then there will be a lag when the estimated angle returns to 0 °.
I used A = 0 for complementary filters.
98, the time constant of about 0 is given.
25 seconds, dt is set to 5 milliseconds.
I found the result to be comparable to the Madgwick filter, better than my first project, but still not reaching a stable balance.
The search continues.
Use of location feedback (encoders)
The gear DC motor I chose for this robot includes the encoder to provide feedback on the motor\'s stator motion.
The encoders are on the motor shaft before the gears occur, so they provide quite high resolution in motion
Depending on the gear ratio and diameter wheel used, I determine that each encoder transitions ~ 0. 04cm.
Then, by calculating the conversion of the encoder over a regular time interval, and then multiplying the result by 0, the distance and speed are very simple.
04 get the distance and divide the distance by the time interval (20 MS in my case)to get speed.
I am planning my next project to solve the navigation capabilities of the robot in a more comprehensive way, so I will not discuss it in detail here, however, two methods are used to control the speed of the robot-setting the target angle and directly adding the motor PWM value.
Adding speed control does eliminate the \"wandering\" of the robot, but does not significantly improve the balance.
Control the way back.
The control loop variables and the main control loop of the structural balance robot are based on two elements-determining the fusion filter of the robot\'s estimated angle and the PID controller motor control signal generated using the estimated angle.
The idea behind the PID controller is to calculate the error of the control signal relative to the set point, then and the proportion, the integral and derivative form of the error, after they are multiplied by individual constants.
The PID controller is widely used as a control element to access the location of the error (I)
Where is it now (P)
And where it goes (D).
But warning in advance.
Optimizing the multiplier for P, I, and D terms can be a very challenging task.
Figure 2 is a square diagram showing the basic structure and control connectivity, reflecting the initial configuration of the robot.
After careful inspection, you may notice that the derivative of the estimated angle is adopted by item D of the PID controller, which will result in the estimated angle change rate.
If you remember, the gyro provides only an angle rate of change, but this rate of change is much more accurate.
This leads people to wonder how the control loop will run if the gyro output is used directly instead of recalculating the angular rate from an estimated angle.
After directly powering the gyro in item D of the PID, the change in balance performance is very significant.
Figure 3 shows why-it shows the gyro output with the pid d term.
The angular rate of change derived from an estimated angle lags behind the gyro output of more than 150 MS, and this delay helps explain some jitter in the original configuration balance, making you want to know exactly how it is balanced.
Figure 4 shows the final configuration to input the gyro directly into item D of the PID controller.
While all the areas explored have had some impact on balance performance, it provides more timely and higher fidelity indication of the gyro angle rate, which provides a change in the performance of the robot I am looking
Finally, I found some very significant improvements to the balance of the robot.
I believe there is more to be done, but the platform is well balanced enough to go to the next stage of the project-adding better speed and direction control to navigation.
All areas investigated have some effect on the balance energy, but I will rank them in the following order: from the highest to the lowest impact: the compact size of the Arduino 101 left me deep and used it in this project.
While it does include Bluetooth LE support, the work required to use it as a control port is beyond the requirements of this project, so I chose a simpler solution based on an external Bluetooth module.
That\'s what this simple robot project does.
It\'s time to do it yourself. Enjoy!
This is my second robot project and I have two key motivations-identify and improve the factors that limit the balance performance of the first robot and integrate a more integrated Arduino 101 form factor.
If interested, here is a link to the Instructure of my first balancing robot project.
Key components of the robot include Arduino 101 board, Arduino motor control shield, two 12 v gear DC motors with Encoders and Bluetooth modules.
Finally, the cheap battery can make the robot more mobile, and the matching Android application can make the robot tune and control.
Here are some links to more ingredient details: in this project, I have some ideas on how to improve the balance of the robot: Finally, I was able to make significant improvements in balancing performance, I have to say, I\'m a little surprised by which changes provide the biggest improvements!
The robot chassis is designed in layers that are quite common, using ready-made materials
Each layer has inches of plywood attached to the stand for each layer.
The robot assembly starts with the motor layer, using the dimensions shown in the figure.
Using the 1/4-bit and edge boot on the router, cut 8 slots to install the DC motor and control the wire cut 9 slots for the motor.
The size of the last slot allows the motor wire connector to pass through the hole.
The mounting holes are drilled in every corner and the sink head is on the bottom so that the mounting screw head is flush.
Connect the motor to the plywood layer using a hose fixture.
To achieve a flexible but robust electrical connection of the motor, a 90 degree perforated connector was used, fixed to the motor layer with a custom bracket.
The battery layer is similar, but the battery Velcro band has only two slots.
It includes the same corner mounting holes, but two more larger holes are drilled to route the motor wires to the electronic layer.
To avoid inductive noise, the power supply and control lines are wired on separate columns.
The two batteries are zippered together and secured to plywood with Velcro straps found in a local amateur store.
The electronic layer preparation includes drilling the same mounting and wire management holes, as well as mounting holes for the Arduino board complex and power switch modules.
The top layer contains only 4 corner mounting holes.
I finish the chassis by designing a shock absorber for each corner, built in plastic springs and felt pads, designed to soften the impact of the fall.
It turns out that waterfalls are an integral part of the development of balancing robots.
At the last step of the construction, I used RC truck tires on the robot.
I bought one from a local hobby store, but they are similar to online ones. The axle-to-
Wheel adapter design 10-
32 fixing screws that fix the adapter on the motor shaft.
A slot of 10-
32 nuts are included, allowing the wheels to be connected directly, and the metal tap bit is used to add the thread to the fixing screw hole after the adapter is printed. .
Below is the STL file for 3D printed parts.
I use Autodesk Fusion 360 for design, Cura for slicing, and then PLA printing on simple metal in PrintrBot.
The only tricky thing is the bumper, where I need to use 0.
The thickness of the shell is 4mm to obtain the desired results.
3D print: the wiring diagram shows the wiring connection between the electrical subsystems of the robot.
In order to connect the motor to the motor shield, I used 20 gauge stranded lines as the power supply and the CAT 5 solid wire as the encoder connection.
I used orders extensively.
Rear connector and heat shrink for strong but flexible connection.
I chose Keyestudio Motor Shield because it is cheap and has a small prototype area.
Connectors for Bluetooth modules and motors A and B encoders use 4x1 single row connectors.
I also convert the voltage divider from 12 v of the battery to 3.
The Arduino 101 simulates 3 v of the input on the motor shield.
For connections between resistors, connectors and Arduino pins, separate wires in CAT 5 cables are used.
Note: I don\'t know if there is an error making my motherboard or if they should be shipped this way but I have to shorten V-logic to 3.
There are 3 v on the motor shield and pads on the board.
The pads are empty at the time of delivery and this connection is required to make the motor shield work.
The motor shield and Arduino 101 do not match on the pin assignment of PWMB, which is the pulse width modulation control of the motor B.
The shield has this on pin D11, but the Arduino 101 does not support PWM on the D11.
To fix this, I assigned PWMB to D9 in the Arduino 101 sketch and added a jumper to the motor shield between D9 and d11.
As an additional precaution, I clamp the D11 pin on the motor shield to avoid any possible contention between D9 and D11 on Arduino 101.
The power jack input is included so that the robot can operate with a wired power supply.
I used this extensively in early testing because no battery charge is required and the supply voltage is consistent.
Note: I use the 12 V/5A power brick as a power supply when tying, not to charge the battery.
Power bricks or batteries can all be used as power supplies for robots, but never both.
The battery must be charged with a suitable charger.
I split the robot sketch into 4 files, mainly to improve the readability of the code.
The file and the general content is: the code does reference the Arduino. h, CurieIMU.
H and MadgwickAHRS.
So you need to install the necessary libraries for Arduino 101 for compilation.
I\'m not going to go through the code completely because the code comments are quite good, but some general comments will be made: to adjust the control parameters of the robot and monitor the telemetry data in real time, I have developed a companion Android app.
It was developed using MIT App Inventor 2, which has a lot of educational and training information.
The app is a simple collection of buttons and sliders that allow the user to configure and control the robot.
Above is a screenshot of the app-it\'s very self-usedexplanatory.
A few notes: I have included the aia file so that you can open it in the MIT App Inventor environment to further research or modify the Android App.
Now, let\'s talk about how to improve the balance performance of the robot, which is an interesting part.
I have some ideas on where to start looking, but like any system, it\'s hard to know what the cross-dependent variables are.
So, I just jumped in, not too analytical.
The control loop time interval starts by changing the time interval for evaluating the balance PID.
I measured the default Arduino 101 PWM cycle at 2 MS, my previous project used a value of 20 MS, so I started at 5 MS and doubled the interval until the bot could not balance
The robot is able to balance in 5 ms, but it seems to be too active and oscillate in about 120 ms.
It was able to balance again at 10 mS, but the oscillation speed dropped to 280 mS.
The oscillation cycle returns to about 180 MS at 20 MS, but the response seems to be slow rather than active.
At the age of 40, the response became more sluggish, the balance became unstable, and the robot was not always able to maintain balance.
My conclusion is that while the PID evaluation interval is sure to affect the behavior of the robot and it does have to be higher than some of the lowest speeds in order to be able to balance, this is not a magic bullet.
For the rest of my tests, I used the control loop interval of 5 ms.
Then I moved to the sensor fusion filter.
Why do we need a fusion filter?
In order to answer this question, we need to check the core of the balance system-IMU (
Inertial measuring device.
The IMU consists of two types of sensors-the gyro and the accelerometer.
The gyro measures the angular change rate or angular velocity.
In theory, good angle position estimation can be generated by integrating the output of the gyro.
Unfortunately, the gyro sensors have an effect called drift-that is, they record some small speed of light even when they are still.
So if you only generate an estimated angle by integrating the gyro output, you will have an error that will continue to grow over time-this problem makes the only solution for the gyro out of balance.
Enter the accelerometer.
The value reported by the accelerometer will include the effect of gravity, which is constant, and any other acceleration that will vary depending on the movement of the device.
For the IMU, it\'s the gravity vector we\'re interested in.
The idea of fusion filters is to generate an estimated angle by combining these two sensors.
It is conducive to the gyro of instantaneous output (
Through high pass filter)
However, by measuring the gravity direction of the Earth, the accelerometer outputs for a long time (
Through a low pass filter)
Clear any drift.
We need a fusion filter, but which one?
There are very complete and complex solutions.
The Kalman filter is one of the more prominent fusion filters, but even an engineering degree won\'t allow you to fully understand what\'s in the black box.
For this project, I used a similar but less demanding solution, Madgwick filter.
One of the main reasons I use this filter is-it\'s bundled with Arduino 101!
But the configuration of the IMU in equilibrium-with only one degree of freedom, creates constraints that allow us to use the simpler solution, the complementary filter.
Since the multiplication factor of each term adds up to 1, the complementary filter gets its name.
The structure diagram of the complementary filter is shown in Figure 1.
For the details behind the complementary filter, there are some very good ways to deal with it online, so I only provide the final filter equation above.
In the equation, A is the constant that determines the properties of the filter.
In addition, it should be noted that in the accelerometer angle calculation, we use the small angle approximation-for less ~ Angle of 30 °, sin (θ)≈ θ in radians.
For our robot, it will fall down if the angle is close to 30 °, so this assumption seems to be valid.
So we can skip sin (θ)
There is little impact in this calculation.
Finally, the time constant of the complementary filter is also shown in the figure above.
I tested Madgwick and the complementary filter to see how it affects the balance of the robot.
The Beta of the installed stock Madgwick filter is set to 0.
1, use the define statement in MadgwickAHRS. h header file.
The robot will not balance with this setting-the response is a bit too slow.
Played a circle and found that it was set to 0.
01 best balance is enabled, although the setting has some compromise on absolute angle accuracy.
If you keep the robot at an angle, say 20 °, and then restore it to its upright position, then there will be a lag when the estimated angle returns to 0 °.
I used A = 0 for complementary filters.
98, the time constant of about 0 is given.
25 seconds, dt is set to 5 milliseconds.
I found the result to be comparable to the Madgwick filter, better than my first project, but still not reaching a stable balance.
The search continues.
Use of location feedback (encoders)
The gear DC motor I chose for this robot includes the encoder to provide feedback on the motor\'s stator motion.
The encoders are on the motor shaft before the gears occur, so they provide quite high resolution in motion
Depending on the gear ratio and diameter wheel used, I determine that each encoder transitions ~ 0. 04cm.
Then, by calculating the conversion of the encoder over a regular time interval, and then multiplying the result by 0, the distance and speed are very simple.
04 get the distance and divide the distance by the time interval (20 MS in my case)to get speed.
I am planning my next project to solve the navigation capabilities of the robot in a more comprehensive way, so I will not discuss it in detail here, however, two methods are used to control the speed of the robot-setting the target angle and directly adding the motor PWM value.
Adding speed control does eliminate the \"wandering\" of the robot, but does not significantly improve the balance.
Control the way back.
The control loop variables and the main control loop of the structural balance robot are based on two elements-determining the fusion filter of the robot\'s estimated angle and the PID controller motor control signal generated using the estimated angle.
The idea behind the PID controller is to calculate the error of the control signal relative to the set point, then and the proportion, the integral and derivative form of the error, after they are multiplied by individual constants.
The PID controller is widely used as a control element to access the location of the error (I)
Where is it now (P)
And where it goes (D).
But warning in advance.
Optimizing the multiplier for P, I, and D terms can be a very challenging task.
Figure 2 is a square diagram showing the basic structure and control connectivity, reflecting the initial configuration of the robot.
After careful inspection, you may notice that the derivative of the estimated angle is adopted by item D of the PID controller, which will result in the estimated angle change rate.
If you remember, the gyro provides only an angle rate of change, but this rate of change is much more accurate.
This leads people to wonder how the control loop will run if the gyro output is used directly instead of recalculating the angular rate from an estimated angle.
After directly powering the gyro in item D of the PID, the change in balance performance is very significant.
Figure 3 shows why-it shows the gyro output with the pid d term.
The angular rate of change derived from an estimated angle lags behind the gyro output of more than 150 MS, and this delay helps explain some jitter in the original configuration balance, making you want to know exactly how it is balanced.
Figure 4 shows the final configuration to input the gyro directly into item D of the PID controller.
While all the areas explored have had some impact on balance performance, it provides more timely and higher fidelity indication of the gyro angle rate, which provides a change in the performance of the robot I am looking
Finally, I found some very significant improvements to the balance of the robot.
I believe there is more to be done, but the platform is well balanced enough to go to the next stage of the project-adding better speed and direction control to navigation.
All areas investigated have some effect on the balance energy, but I will rank them in the following order: from the highest to the lowest impact: the compact size of the Arduino 101 left me deep and used it in this project.
While it does include Bluetooth LE support, the work required to use it as a control port is beyond the requirements of this project, so I chose a simpler solution based on an external Bluetooth module.
That\'s what this simple robot project does.
It\'s time to do it yourself. Enjoy!
Custom message
