User Tools

Site Tools


marvin:ecp0

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
marvin:ecp0 [2009/01/28 21:50] sohnmarvin:ecp0 [2009/01/29 11:11] (current) rieper
Line 8: Line 8:
  
 Our original project goal description can be found in its entirety in lab11(([[http://wiki.aasimon.org/?id=marvin:lab11|Lab 11]])) Our original project goal description can be found in its entirety in lab11(([[http://wiki.aasimon.org/?id=marvin:lab11|Lab 11]]))
 +
 +
 +=====Structure of this Document=====
 +This documents is divided into 7 parts. The introduction is the first part and is meant to give a general introduction the project, the LEGO Mindstorm NXT and the software structure as well as the naming conventions for easier reading.\\
 +Each lab report should not be read as a chronological evolution of the project, as there will be subjects mentioned that has not been fully implemented in that particular lab session. The lab reports are used to define different subjects of investigation.\\
 +The following 5 lap reports describes the process and the results.\\
 +  * Lap report 1 describes how the robot was build and how the communication with the gyroscope is handled.\\
 +  * Lap report 2 describes different control architectures, which one we use and how it is implemented to make the robot capable of balancing. Furthermore an introduction to tuning parameters and an evaluation of which features of an error signal to use is presented.\\
 +  * Lap report 3 describes the steps involved in making the robot able to drive forward and backward and from there to be able to drive a predefined pattern. In this session we also present a supplementary section about DC servo motors based on the lectures.\\
 +  * Lap report 4 describes the implementation of behaviour models which include behaviours such as the ability to drive autonomously and avoid obstacles.\\
 +  * Lap report 5 describes how to make the robot remote controlled utilizing BlueTooth.\\
 +Finally there is a discussion/evaluation of the obtained results and a conclusion of the project as a whole.\\
 +
  
 =====Motivation===== =====Motivation=====
-This problem of balancing an inverted pendulum is a nice delicate control problem and it has become the “Holy Grail” for many robot hobbyists around the world. The task of balancing a two wheeled robot may sound simple, but in reality many people have tried – and failed. In LAB4(([[http://wiki.aasimon.org/?id=marvin:lab4|Lab 4]])) we tried to make a self-balancing LEGO robot inspired by Steve Hassenplug's original Legway(([[http://www.teamhassenplug.org/robots/legway/|Legway]])) controlled by the RCX using light sensors – and failed. The task it not trivial as it requires knowledge and basic understanding of sensors, actuators and tuning parameters in the control loop. These challenges are appealing to us and we had many ideas of how to improve the implementation from LAB4(([[http://wiki.aasimon.org/?id=marvin:lab4|Lab 4]])). These ideas have laid the foundation of this final project, but we are not satisfied by making a simple balancing robot. In terms of the greater field of robotics, the balancing robot is almost purely mechanical, precluding the need for higher-level planning or behavioural programming that a more complex robot might require. Inputs over (discrete) time in the form of pendulum position readings are mapped algorithmically to output in the form of motor control. So we wanted to expand the project by adding behavioural programming using simple behaviours executed by a priority system. The motivation for behavioural programming was founded in LAB8(([[http://wiki.aasimon.org/?id=marvin:lab8|Lab 8]])), where we refer to some basic ideas of behaviour control.  +This problem of balancing an inverted pendulum is a nice delicate control problem and it has become the “Holy Grail” for many robot hobbyists around the world. The task of balancing a two wheeled robot may sound simple, but in reality many people have tried – and failed. In LAB4(([[http://wiki.aasimon.org/?id=marvin:lab4|Lab 4]])) we tried to make a self-balancing LEGO robot inspired by Steve Hassenplug's original Legway(([[http://www.teamhassenplug.org/robots/legway/|Legway]])) controlled by the RCX using light sensors – and failed. The task it not trivial as it requires knowledge and basic understanding of sensors, actuators and tuning parameters in the control loop. These challenges are appealing to us and we had many ideas of how to improve the implementation from LAB4(([[http://wiki.aasimon.org/?id=marvin:lab4|Lab 4]])). These ideas have laid the foundation of this final project, but we are not satisfied by making a simple balancing robot. In terms of the greater field of robotics, the balancing robot is almost purely mechanical, precluding the need for higher-level planning or behavioural programming that a more complex robot might require. Inputs over (discrete) time in the form of pendulum position readings are mapped algorithmically to output in the form of motor control. So we wanted to expand the project by adding behavioural programming using simple behaviours executed by a priority system. The motivation for behavioural programming was founded in LAB8(([[http://wiki.aasimon.org/?id=marvin:lab8|Lab 8]])), where we refer to some basic ideas of behaviour control. (for more advanced behaviour modelling look up Maja J Mataric)  
-Another great motivation factor has been all the great videos from [[http://www.youtube.com|Youtube]], where many people have tried to make a balancing robot using the LEGO Mindstorm kit. Most of them are very unstable and only capable of standing still, so it seems as a great challenge to make a remote controlled driving balancing robot with implemented behaviour models enabling the robot to interact with the environment. We were especially impressed with the outstanding implementation by Yorihisa Yamamoto(([[http://www.youtube.com/watch?v=4ulBRQKCwd4|Yorihisa Yamamoto's nxtway-gs]])).+Another great motivation factor has been all the great videos from [[http://www.youtube.com|Youtube]], where many people have tried to make a balancing robot using the LEGO Mindstorm kit. Most of them are very unstable and only capable of balancing, so it seems as a great challenge to make a remote controlled driving balancing robot with implemented behaviour models enabling the robot to interact with the environment. We were especially impressed and inspired by the outstanding implementation by Yorihisa Yamamoto(([[http://www.youtube.com/watch?v=4ulBRQKCwd4|Yorihisa Yamamoto's nxtway-gs]])).
  
-{{:marvin:legway.jpg?200|The original RCX Legway}} +{{ :marvin:legway.jpg?200 |The original RCX Legway}} 
-{{:marvin:japanmarvin.png?200|Yorihisa Yamamoto's balancing robot}}+{{ :marvin:japanmarvin.png?200 |Yorihisa Yamamoto's balancing robot}}
  
 =====Literature Review===== =====Literature Review=====
Line 22: Line 35:
 School of Mechanical Engineering, Final Year Thesis 2003)) a two-wheeled differential driven mobile robot based on the inverted pendulum model is built as a platform to investigate the use of a Kalman filter for sensor fusion. The sensor fusion technique using a Kalman filter is a highly researched area and the idea is to combine different sensors in order to ensure higher stability in a given measurement. A common choice of sensor for a balancing robot is the gyro as it can measure the deviation from equilibrium. In practise however, the gyro tends to drift over time and thereby altering the reference value of the control system, hence making the entire system unstable. If we combine other sensors utilizing a Kalman filter we may be able to compensate for this drifting behaviour and keep the system in equilibrium. In the project an evaluation of the performance of a Linear Quadratic Regulator (LQR) and a Pole-placement controller is given as well. All calculations are presented analytically based on a derived dynamic model for a two wheeled inverted pendulum. Although the project illustrates some very exciting and relevant concepts, we have chosen to omit the use of sensor fusion since the Kalman Filter implementation would be beyond the scope of this project. Regarding the control loop we have no theoretical knowledge of the LQR control and again it would be unwise to focus on this type of control in our project. The pole placement controller is a possibility, but we considered this approach somewhat risky as this system will be unstable if the poles are placed too far on the left-hand plane. Therefore we decided to use a PID controller, which hopefully will prove to be adequate. In LAB4(([[http://wiki.aasimon.org/?id=marvin:lab4|Lab 4]])) we found quite promising results using light sensors and a PID controller.     School of Mechanical Engineering, Final Year Thesis 2003)) a two-wheeled differential driven mobile robot based on the inverted pendulum model is built as a platform to investigate the use of a Kalman filter for sensor fusion. The sensor fusion technique using a Kalman filter is a highly researched area and the idea is to combine different sensors in order to ensure higher stability in a given measurement. A common choice of sensor for a balancing robot is the gyro as it can measure the deviation from equilibrium. In practise however, the gyro tends to drift over time and thereby altering the reference value of the control system, hence making the entire system unstable. If we combine other sensors utilizing a Kalman filter we may be able to compensate for this drifting behaviour and keep the system in equilibrium. In the project an evaluation of the performance of a Linear Quadratic Regulator (LQR) and a Pole-placement controller is given as well. All calculations are presented analytically based on a derived dynamic model for a two wheeled inverted pendulum. Although the project illustrates some very exciting and relevant concepts, we have chosen to omit the use of sensor fusion since the Kalman Filter implementation would be beyond the scope of this project. Regarding the control loop we have no theoretical knowledge of the LQR control and again it would be unwise to focus on this type of control in our project. The pole placement controller is a possibility, but we considered this approach somewhat risky as this system will be unstable if the poles are placed too far on the left-hand plane. Therefore we decided to use a PID controller, which hopefully will prove to be adequate. In LAB4(([[http://wiki.aasimon.org/?id=marvin:lab4|Lab 4]])) we found quite promising results using light sensors and a PID controller.    
  
-Now let us turn towards the LEGO projects, which are numerous judging from the Youtube homepage. Two projects deserve special attention. Steven Hassenplug (([[http://www.teamhassenplug.org/robots/legway/|Legway]])) has successfully constructed a balancing robot called Legway using the LEGO Mindstorms robotics kit. Two Electro-Optical Proximity Detector (EOPD) sensors is used to provide the tilt angle of the robot to the controller which is programmed in BrickOS, a C/C++ like programming language specifically for LEGO Mindstorms. This project was probably the first balancing robot using the Lego Mindstorm system and sparked many similar projects as this was an affordable platform for many hobbyists. A more recent project called NXTway-GS, written by Yorihisa Yamamoto(([[http://www.mathworks.com/matlabcentral/fileexchange/19147|Yorihisa Yamamoto's Project]])), is a self-balancing two-wheeled robot built with LEGO Mindstorms NXT and a Hitechnic gyroscope sensor. The final results of this project is very impressive and can be youtube(([[http://www.youtube.com/watch?v=EHPlGTLQHRc|nxtway-gs simulation]])),(([[http://www.youtube.com/watch?v=4ulBRQKCwd4|nxtway-gs driving]])). Since this ultimately proves that a balancing system can be made using a gyroscope, we decided to use the exact same model by means of a building manual from the web page. The complete analytical solution by Yamamoto is somewhat complex, but this is mainly due to the simulation part of the project. With the physical model and sensors from this project, it should be possible to create our own balancing robot utilizing a simple PID controller.+Now let us turn towards the LEGO projects, which are numerous judging from the Youtube homepage. Two projects deserve special attention. Steven Hassenplug (([[http://www.teamhassenplug.org/robots/legway/|Legway]])) has successfully constructed a balancing robot called Legway using the LEGO Mindstorms robotics kit. Two Electro-Optical Proximity Detector (EOPD) sensors is used to provide the tilt angle of the robot to the controller which is programmed in BrickOS, a C/C++ like programming language specifically for LEGO Mindstorms. This project was probably the first balancing robot using the Lego Mindstorm system and sparked many similar projects as this was an affordable platform for many hobbyists. A more recent project called NXTway-GS, written by Yorihisa Yamamoto(([[http://www.mathworks.com/matlabcentral/fileexchange/19147|Yorihisa Yamamoto's Project]])), is a self-balancing two-wheeled robot built with LEGO Mindstorms NXT and a Hitechnic gyroscope sensor. The final results of this project is very impressive and can be seen on youtube(([[http://www.youtube.com/watch?v=EHPlGTLQHRc|nxtway-gs simulation]])) (([[http://www.youtube.com/watch?v=4ulBRQKCwd4|nxtway-gs driving]])). Since this ultimately proves that a balancing system can be made using a gyroscope, we decided to use the exact same model by means of a building manual from the web page. The complete analytical solution by Yamamoto is somewhat complex, but this is mainly due to the simulation part of the project. With the physical model and sensors from this project, it should be possible to create our own balancing robot utilizing a simple PID controller.
  
  
Line 40: Line 53:
 =====Hardware===== =====Hardware=====
 This section introduces the hardware used in this project. The sensors/actuators will be introduced further in the relevant lab sessions. This section introduces the hardware used in this project. The sensors/actuators will be introduced further in the relevant lab sessions.
 +
  
 ====NXT Module==== ====NXT Module====
-{{:marvin:p_intro_brick.png|NXT Module}}+{{:marvin:p_intro_brick.png}}
  
-The NXT(([[http://mindstorms.lego.com/eng/Overview|Lego Mindstorm]])) is the brain of a MINDSTORMS® robot. +The NXT(([[http://mindstorms.lego.com/eng/Overview|LEGO Mindstorm]])) is the brain of a MINDSTORMS® robot. 
  
-===Motor ports=== +===Motor Ports=== 
-The NXT has three output ports for attaching motors - Ports A, B and C +The NXT has three output ports for attaching motors - Ports A, B and C.
  
-===Sensor ports===+===Sensor Ports===
 The NXT has four input ports for attaching sensors - Ports 1, 2, 3 and 4.  The NXT has four input ports for attaching sensors - Ports 1, 2, 3 and 4. 
  
-===USB port===+===USB Port===
 Connect a USB cable to the USB port and download programs from the computer to the NXT (or upload data from the robot to the computer). It is also possible to use the wireless Bluetooth connection for uploading and downloading. Connect a USB cable to the USB port and download programs from the computer to the NXT (or upload data from the robot to the computer). It is also possible to use the wireless Bluetooth connection for uploading and downloading.
  
-===Technical specifications=== +===Technical Specifications=== 
   * 32-bit ARM7 microcontroller    * 32-bit ARM7 microcontroller 
   * 256 Kbytes FLASH, 64 Kbytes RAM    * 256 Kbytes FLASH, 64 Kbytes RAM 
Line 65: Line 79:
   * 3 output ports, 6-wire cable digital platform    * 3 output ports, 6-wire cable digital platform 
   * 100 x 64 pixel LCD graphical display    * 100 x 64 pixel LCD graphical display 
-  * Loudspeaker - 8 kHz sound quality. Sound channel with 8-bit resolution and 2-16 KHz sample rate. +  * Loudspeaker - 8 kHz sound quality. Sound channel with 8-bit resolution and 2-16 kHz sample rate. 
   * Power source: 6 AA batteries    * Power source: 6 AA batteries 
  
Line 74: Line 88:
  
  
-====The Sonic Sensor====+ 
 +====The Ultrasonic Sensor====
 {{:marvin:sonic.png}} {{:marvin:sonic.png}}
  
Line 82: Line 97:
 {{:marvin:motor.png}} {{:marvin:motor.png}}
  
-There are three Servo Motors included in the Mindstorm kit. Each motor has a built-in Rotation Sensor. This lets your control your robot’s movements precisely. The Rotation Sensor measures motor rotations in degrees or full rotations [accuracy of +/- one degree]. One rotation is equal to 360 degrees, so if you set a motor to turn 180 degrees, its output shaft will make half a turn. The built-in Rotation Sensor in each motor also lets you set different speeds for your motors [by setting different power parameters in the software]. The motors have sufficient power in order to make the robot balance.+There are three Servo Motors included in the Mindstorm kit. Each motor has a built-in Rotation Sensor. This lets your control your robot’s movements precisely. The Rotation Sensor measures motor rotations in degrees or full rotations (accuracy of +/- one degree). One rotation is equal to 360 degrees, so if you set a motor to turn 180 degrees, its output shaft will make half a turn. The built-in Rotation Sensor in each motor also lets you set different speeds for your motors (by setting different power parameters in the software). The motors have sufficient power in order to make the robot balance. 
  
 =====Software===== =====Software=====
-The code is purely written in the Java syntax through the Lejos NXT framework.\\ +The code is purely written in the Java syntax through the LeJOS NXT framework(([[http://lejos.sourceforge.net/|LeJOS]])).\\ 
-We use CamelCase notation (([[http://en.wikipedia.org/wiki/CamelCase|Wikipedia CamelCase]])) for both the methods and variable names.\\ +We use CamelCase notation(([[http://en.wikipedia.org/wiki/CamelCase|Wikipedia CamelCase]])) for both the methods and variable names.\\ 
-All classes are fully documented by the javadoc documentation conventions (([[http://java.sun.com/j2se/javadoc/writingdoccomments/index.html|Javadoc Documentation]])).+All classes are fully documented by the javadoc documentation conventions(([[http://java.sun.com/j2se/javadoc/writingdoccomments/index.html|Javadoc Documentation]])).
  
-====Class overview====+====Class Overview====
 {{ :marvin:classes.png?450 }} {{ :marvin:classes.png?450 }}
 The above figure illustrates all the important classes in the project as well as their relations to each other. The above figure illustrates all the important classes in the project as well as their relations to each other.
Line 98: Line 114:
 Take note that printing out to the LCD is a very expensive task, and since the art of balancing is very sensitive, the print class cannot be used while actually running. Take note that printing out to the LCD is a very expensive task, and since the art of balancing is very sensitive, the print class cannot be used while actually running.
  
-=====The name=====+=====The Name=====
 The name //"Marvin"// has been taken from //"The Hitchhikers Guide to the Galaxy"// in which an android bears that exact name. He is also called //"Marvin, the paranoid android"//(([[http://en.wikipedia.org/wiki/Marvin the Paranoid Android|Paranoid Android]])), which refers to his sad mood, caused by a severe depression, and boredom, a behaviour we saw mirrored in the way our particular robot was moving and behaving. The name //"Marvin"// has been taken from //"The Hitchhikers Guide to the Galaxy"// in which an android bears that exact name. He is also called //"Marvin, the paranoid android"//(([[http://en.wikipedia.org/wiki/Marvin the Paranoid Android|Paranoid Android]])), which refers to his sad mood, caused by a severe depression, and boredom, a behaviour we saw mirrored in the way our particular robot was moving and behaving.
  
-=====Structure of this Document===== +
-This documents is divided into 7 parts. This introduction is the first part. This is meant to give a general introduction to the Lego Mindstorm NXT universe.  +
-The following 5 lap reports describes the process and the results.\\ +
-Lap report 1 describes how the robot was build and how the communication with the gyroscope is handled.\\ +
-Lap report 2 describes different control architectures , which one we use and how it is implemented to make the robot capable of balancing. Furthermore an introduction to tuning parameters and an evaluation of which features of an error signal to use is presented.\\ +
-Lap report 3 describes the steps involved in making the robot able to drive forwards and backwards on from there able to drive at a predefined pattern.\\ +
-Lap report 4 describes the implementation of behaviour models which include behaviours such as the ability to drive autonomously and avoid obstacles.\\ +
-Lap report 5 describes how to make the robot remote controlled utilizing BlueTooth.\\ +
-Finally there is a discussion about the results and a conclusion of the project as a whole.\\+
marvin/ecp0.1233175819.txt.gz · Last modified: 2009/01/28 21:50 by sohn