Date:
2/12 2010
Duration of activity:
6 hours
Group members participating:
Frederik, Christian & Lasse
Goals:
To determine which sensors to use in the project by investigating available sensors and previous projects experience with these.
Plan:
1. Investigate available sensors
2. Investigate earlier projects experience with different sensors for balancing a robot.
3. Construct the physical platform for a balancing robot.
4. Consider control strategy
3. Construct the physical platform for a balancing robot.
4. Consider control strategy
Results:
1. Available sensors
The most obvious sensors to use for monitoring if the robot is balancing are:
- Accelerometer (or tilt sensor)
- Gyrometer
- Light sensor
- EOPD sensor
The difference in how these sensors work are:
- Accelerometer: Measures the acceleration along an axis (one or more, depending on the accelerometer type). This includes gravitational acceleration.
- Gyrometer: Measures rotation speed along an axis.
- Light sensor: Measures intensity of light.
- EOPD: The same as the light sensor but more advanced.
According to the leJOS documentation [6] all of these sensors are supported by the leJOS API if you stick with the brand HiTechnic. The GyroSensor class, however, is untested according to the documentation.
According to a post on the mindsensors.com forum [7] the processing speed of the NXT is not fast enough to use just the accelerometer. This might be because the mathematics required for obtaining the required data from just the accelerometer is quite complex. Here the gyrometer is recommended for balancing a robot.
We have previously used a light sensor for balancing a robot [8]. Our experience with this is that the sensor is very influenced by the ambient lighting conditions in the environment. Besides that, the sensor readings are also afftected by the texture and color of the reflecting surface. This makes it difficult to utilize the sensor for a balancing robot, if the surface does not have a consistent texture, and color.
The EOPD sensor is somewhat more advanced than the regular light sensor, as the sensor is immune to changes in the ambient lighting [9]. The issues with the reflecting surface, however, are the same as the regular light sensor.
The EOPD sensor could be used as a sensor for detecting if the robot is on the ground, or if the robot has fallen. This information could be used for e.g. stopping the motors when the robot has been lifted off of the ground, or deploying some sort of strategy for getting the robot back in action.
The most obvious sensors to use for monitoring if the robot is balancing are:
- Accelerometer (or tilt sensor)
- Gyrometer
- Light sensor
- EOPD sensor
The difference in how these sensors work are:
- Accelerometer: Measures the acceleration along an axis (one or more, depending on the accelerometer type). This includes gravitational acceleration.
- Gyrometer: Measures rotation speed along an axis.
- Light sensor: Measures intensity of light.
- EOPD: The same as the light sensor but more advanced.
According to the leJOS documentation [6] all of these sensors are supported by the leJOS API if you stick with the brand HiTechnic. The GyroSensor class, however, is untested according to the documentation.
According to a post on the mindsensors.com forum [7] the processing speed of the NXT is not fast enough to use just the accelerometer. This might be because the mathematics required for obtaining the required data from just the accelerometer is quite complex. Here the gyrometer is recommended for balancing a robot.
We have previously used a light sensor for balancing a robot [8]. Our experience with this is that the sensor is very influenced by the ambient lighting conditions in the environment. Besides that, the sensor readings are also afftected by the texture and color of the reflecting surface. This makes it difficult to utilize the sensor for a balancing robot, if the surface does not have a consistent texture, and color.
The EOPD sensor is somewhat more advanced than the regular light sensor, as the sensor is immune to changes in the ambient lighting [9]. The issues with the reflecting surface, however, are the same as the regular light sensor.
The EOPD sensor could be used as a sensor for detecting if the robot is on the ground, or if the robot has fallen. This information could be used for e.g. stopping the motors when the robot has been lifted off of the ground, or deploying some sort of strategy for getting the robot back in action.
2. Earlier projects
This section describes the observations we have done by reading the lab reports of earlier projects.
2a. Annette et al. [1]
Annette et al. had the initial goal of making a robot balance through the Alishan track. They chose to use the gyro sensor for balancing which caused a lot of problems because of the drift in the sensor. The project goal changed to only focus on the drifting problem which they never managed to solve. They have some observations, though, that we can benefit from. For example they had a theory that the gyro offset gets fairly stable after 5-8 minuter, but they didn't prove it for some reason. Furthermore they read from a source that the gyro sensor requires at least 10 seconds warm up time. They suggested future groups to measure and investigate the drift over a longer period of time, say 30 min.
2b. Marvin [2]
Annette et al. based some of their work on a balancing robot project done in an earlier semester called Marvin. Marvin used a running average on the offset to minimize the drifting problem but Annette et al. didn't try that out, so this approach is surely relevant for us. To improve the balancing algorithm the Marvin group also used the tacho counter for the motors along with the gyro sensor to determine if the robot is still.
2c. Sejway [3]
This project focused on developing a selfbalancing robot based on sensor readings from a high precision lightsensor "EOPD" and a gyrosensor - both from HiTechnic [4].
The EOPD sensor proved to be very precise at measuring distances <5cm. Therefore an installation of the sensor must be close to the surface to ensure precise readings. The sensor output values are not absolute on different surfaces, but are not affected by ambient light. This means that when used on a flat, plain and single-color surface, the EOPD sensor output will be sufficient for determining robot angle. In a fall-test comparison of sensor output from gyro and EOPD, the EOPD sensor proved to react faster than gyro, hence producing more outputs pr. second.
The gyro sensor outputs values as degrees/second. The sensor values has an offset that's individual to each sensor, and some software calibration is therefore needed when installing a new sensor.
The regulation method used for this project was a PID-controller. The PID-values were hard for the group to determine, as they fairly late in the process managed to produce a proper robot design.
The physical construction of the robot turned out to be the determining factor of the project. They concluded that it was alpha and omega to have a robot design that is "ment for a balancing robot". Their solution was to create a weight-mechanism consisting of two large wheels on a lever. These weights could then be shifted on the lever in order to change the center of gravity.
3. Construction of robot
We found a physical design for a balancing robot made by Yorihisa Yamamoto [5]. As we didn't want to reinvent a robot, and as Y. Yamamoto had made this design work, we decided to use his construction as a base for our balancing robot.
We modified his design to fit our own needs - i.e. omitting unnecessary sensors, and slight construction changes for the sensor fitting.
3. Construction of robot
We found a physical design for a balancing robot made by Yorihisa Yamamoto [5]. As we didn't want to reinvent a robot, and as Y. Yamamoto had made this design work, we decided to use his construction as a base for our balancing robot.
We modified his design to fit our own needs - i.e. omitting unnecessary sensors, and slight construction changes for the sensor fitting.
A block diagram showing the final composition of the robot is shown on Figure 1. Note that even though the accelerometer is shown on the diagram, it wasn't mounted in this session.
Figure 1 - Composition of the balancing robot
The balancing robot acts as an inverted pendulum [10] - more specific as a the type cart and pole. Briefly explained, an inverted pendulum is like a regular pendulum, but with its mass above its pivot point. This of course makes the construction inherently unstable, and must be constantly corrected to keep the balance.
In our case the balancing will be done by continuously regulating the horizontal position of the pivot point by applying momentum to the wheels. This will make sure that the pivot point is (more or less*) directly under the centre of gravity. This will be part of a feedback system, which will be described at a later session.
*depending on our succes with the balancing act.
The resulting construction can be seen on Figures 2 and 3.
Figure 2 - The balancing robot construction (front)
Figure 3 - Rear view of the robot with the gyro sensor mounted
4. Considerations about control strategy
The way we intend to make the robot balance is by employing a feedback system using reactive control [11]. When the system detects that the robot is losing its balance (stimulus) via the sensor input, it will react by turning the wheels in one or the other direction - counteracting the loss of balance, and hopefully regain control.
The concept of this is depicted on Figure 4.
The concept of this is depicted on Figure 4.
Figure 4 - Concept of stimulus-response system
The concept of this is that the system gets stimuli on the current situation from the environment via the sensors. Based on this information, the system will make a response, which in turn will "update" the environment, and new stimuli will be sensed.
Ideally this continuous stimulus-response loop will maintain status quo for our system, and - hopefully - make our robot balance.
Conclusion:
We found out that previous balancing robot projects all had problems with the drift in the gyro sensor and put a lot of work into getting it to behave satisfactory. We have decided that we won't make another balancing robot project with main focus on the gyro sensor. Instead we want to investigate alternative methods both by means of different sensors and regulation methods.
The derived value from the gyrometer should be the same value as an accelerometer would output, but since no earlier project has experimented with theese, we would like to see if the accelerometer yields better results than the derived gyro value.
A gyro sensor was available at the Lego Lab. We ordered two accelerometers at HiTechnic [4]. This means that we have to wait approximately a week until we can do experiments with the sensor
The EOPD sensor and lightsensors in general are limited to work on even, plane, single-color surface and will therefore only work in a controlled environment which requires a large amount of calibration before use. Even though the EOPD sensor is not influenced by ambient light, it still reacts different to color and texture. We would like to avoid this and has therefore chosen not to use the EOPD sensor.
We wanted to base the construction of the Lego robot on an existing design that has proven to be successful. Yorihisa Yamamoto [5] has constructed and implemented a robust balancing robot and even made a thorough construction manual, so we chose his design. The design is seen on Figure 1 and 2.
Based on previous experience gained in the lab sessions we wanted to make it easier to debug and change parameters runtime. The idea is to have the robot reporting state to a PC application and the PC application shall also be capable of sending values to the robot and thereby change control parameters runtime.
The code for this session is found here [12].
The code for this session is found here [12].
References:
[1] Annette et al., "Balancing robot", http://annettesamuelrasmus.blogspot.com/
[2] Johnny Rieper et al., "Marvin - project report 3", http://wiki.aasimon.org/doku.php?id=marvin:ecp3
[3] Sejway. Rasmus Gude et al. http://lego.secretman.dk/wiki
[4] HiTechnic http://www.hitechnic.com/
[5] Yorihisa Yamamoto, "NXTway-GS Building Instructions", http://dl.dropbox.com/u/2389829/Lego/Session%201/NXTway-GS%20Building%20Instructions.pdf
[6] leJOS NXJ API documentation, http://lejos.sourceforge.net/nxt/nxj/api/index.html
[7] mindsensors.com forums, "ACCEL sensor programming in NXT-G", http://www.mindsensors.com/forums/viewtopic.php?f=5&t=48
[8] Lego-lab 4, Christian Jensen, Frederik Laulund, Lasse H. Rasmussen, http://chrfredelasse.blogspot.com/2010/09/lab-exercise-4.html
[9] HiTechnic Blog, "EOPD – How to measure distance", http://www.hitechnic.com/blog/eopd-sensor/eopd-how-to-measure-distance/
[10] Inverted pendulum, Wikipedia, http://en.wikipedia.org/wiki/Inverted_pendulum
[11] Fred G. Martin, Robotic Explorations: A Hands-On Introduction to Engineering, Prentice Hall, 2001, Ch. 5: "Control"
[12] L., Rasmussen, F., Laulund & C., Jensen, Session 1 source code, http://dl.dropbox.com/u/2389829/Lego/Session%201/Sesssion%201%20source%20code.zip
[5] Yorihisa Yamamoto, "NXTway-GS Building Instructions", http://dl.dropbox.com/u/2389829/Lego/Session%201/NXTway-GS%20Building%20Instructions.pdf
[6] leJOS NXJ API documentation, http://lejos.sourceforge.net/nxt/nxj/api/index.html
[7] mindsensors.com forums, "ACCEL sensor programming in NXT-G", http://www.mindsensors.com/forums/viewtopic.php?f=5&t=48
[8] Lego-lab 4, Christian Jensen, Frederik Laulund, Lasse H. Rasmussen, http://chrfredelasse.blogspot.com/2010/09/lab-exercise-4.html
[9] HiTechnic Blog, "EOPD – How to measure distance", http://www.hitechnic.com/blog/eopd-sensor/eopd-how-to-measure-distance/
[10] Inverted pendulum, Wikipedia, http://en.wikipedia.org/wiki/Inverted_pendulum
[11] Fred G. Martin, Robotic Explorations: A Hands-On Introduction to Engineering, Prentice Hall, 2001, Ch. 5: "Control"
[12] L., Rasmussen, F., Laulund & C., Jensen, Session 1 source code, http://dl.dropbox.com/u/2389829/Lego/Session%201/Sesssion%201%20source%20code.zip