torsdag den 22. maj 2014

Final Project - Lesson 3

Lesson 3

Date: 15/05 2014
Duration of activity: 09.15 - 14.45
Group members participating: Pætur Askildsen, Christian Hansen, Søren Gregersen, Søren Ditlev and Alexander Rasmussen

Goal
Start work on our tube-balancing robot.
Plan
  • Find a suitable tube, that is large enough to fit the 16.5 cm wide car. Alexander and Søren G. will be set on this task
  • Construct the tube-balancing robot, a robot that can balance on top of the tube. Søren G. and Alexander will also do this.
  • Build a Bluetooth remote control for the car inside the tube and work on the code for the remote controller and the car inside the tube. Pætur will work on this.
  • Understand, tweak and error-check the code found last time [1] including a PID-controller for the balancing robot and and begin transforming this code into a tube-balancing context usage. Søren D. and Christian will work on this.
Results

Finding a tube

We were able to get our hands on large polystyrene tube. It is 35 cm in diameter which is large enough for our purpose. Furthermore the polystyrene is a very light material which makes the tube lightweight as well, this might be an advantage because it makes it easier for the robot inside the tube to make the tube roll. It may also be a disadvantage, as a heavier tube would result in slower turns, thus giving the tube balancing robot more time to adjust. This logic is derived from information found in session 1, where we found out about the ball for ballbots:
A high friction coefficient of its surface and a low inertia are essential. The CMU Ballbot[3] and Rezero[27]) used a hollow metal sphere with poly-urethane coating. B.B. Rider[22]used a basketball, while BallIP[24] and Adelaide Ballbot[35] used bowling balls coated with a thin layer of rubber. [2].

Figure 1: The polystyrene tube used in the project

Constructing the Tube-Balancing Robot

We constructed a car which we think have the specifications needed to balance on the polystyrene tube. The wheelbase of the car is 25 cm, see figure 2. The axles are tipped 45 degrees to accommodate the curvature of the tube. The car is driven by a single motor since we only need control in one axis - back and forth. At the front end of the car we have only mounted a single wheel, we did this to give the car a more dramatic look, but it does not compromise the balance of the car significantly. At the very center of the car we mounted the gyroscope so that it is perfectly leveled with the car’s alignment to the tube.         
Figure 2: The first version of the balancing robot.


The first tests quickly showed, that the robot was not working well with only one front wheel, since it quickly turned right [3], link to video. Our assumption that one wheel does not compromise the balance of the car was wrong. Therefore one additional wheel was mounted on the car, and the third version can be seen in figure 3 below.
Figure 3: The second version of the balancing robot, now with two wheels both at the front and rear end of the car.

The remote controller

The car inside the tube shall only drive forwards and backwards, therefore we built a remote controller with one lever that is connected to a NXT motor. This construction was just a fast mockup for testing and it can be seen in figure 4.


Figure 4: The bluetooth remote to control the car inside the tube

The inspirational code

The inspirational code can be found here in two zip-folders [1]. The LegoControl.zip contains the code for a remote controller and the Legway.zip contains the code for the LegWay that is controlled by this remote controller. Our balancing robot shall not be remote controlled but the car inside the tube shall be remote controlled. This means that the code in Legway.zip has been split in two parts: One with the balancing robot and the other with the remote controlling.

Code for the balancing robot, including PID-controller

The code for the balancing robot has been reorganized and variables have been renamed. The code has been commented on by comparing it to the original NXC code [4] which helps us understand the code written by others. Now the code for the balancing robot is easily understood. This code clean-up procedure was also to remove any unnecessary code.
The 4-parameter linear balancing equation from HiTechnic HTWay Version 1.1. [4] , see figure 5 for code translated to Java, is used as input to a PID-controller, see figure 6, instead of using this directly to power the motor, which is the approach HTWay uses. For the PID-controller we have omitted the time constant, dT, for the integral and derivative term as described in [5].
Figure 5: The linear balancing equation, used as input to a PID-controller.
Figure 6: The PID-controller.

Code for the remote controller

All the code for the remote controlling has been combined into one project of its own apart from the code for the balancing robot. Here comments have been added and unnecessary code has been removed as well as code has been added. An example of this that the remote controlled LegWay could drive forwards and turn, but our remote controlled car shall drive forwards and backwards, so all code for turning has been removed and the code for making it drive backwards has been added.


The original remote controller was calibrated at each launch, which is necessary because it uses the tacho counter to calculate the speed. We decided to stick with the calibration of the remote controller since this also makes it possible to rebuild the controller without having to rewrite the code for it controller. However we had to alter the code for calibrating the remote so that the car inside the tube can drive backwards as well.


The calibration is a two-step process and the instructions for calibrating the remote controller are shown on the display on launch and they are as follows:
  1. Set the lever to the lowest position and press Enter
  2. Set the lever to the highest position and press Enter
The values from the tacho counter in this two step calibration are mapped to the highest possible speed backwards and the highest possible speed forwards, which are -100 and 100 respectively. The code for the calibration can be seen in figure 7.
Figure 7: The calibration of the remote controller.
Conclusion
Today we have made two versions of the balancing robot. The first one with only one front wheel, and the second with two front wheels. We found that the first version was not stable enough to drive on the tube. We have also succeeded in adapting the code to our tube-balancing context so it made the robot drive on the tube for a few seconds. From now on there is a lot of trial and error tuning the parameters, possibly also understanding and adjusting the code more.
The remote control has also been built. The calibration of the remote controller has been programmed but there is still some programming to do before it works. Remember that the remote control should be used to drive the car inside of the tube.  
Plan for next session(s)
Adjust the code so that the balancing robot only uses the gyro readings and not the tacho counter (we have a hypothesis that the tacho counter is only necessary when the robot, in the LegWay, needs to balance on the floor). Tacho counter may not be needed since we want to make less subtle movements, in order to react on the tubes movements. The PID-parameters should also be adjusted.
We want to get the remote controller to communicate with the car inside the tube using Bluetooth. Hopefully the remote controller can be finished next time.


The steps should be prioritized as follows, so we start out simple:
  1. Make the car balance on top of the tube by itself.
    1. Adjust PID (maybe do this through Bluetooth to ease adjustment overhead).
    2. Try removing tacho counter and rely solely on gyroscope readings
  2. When this works, add the remotely controlled car inside the tube to also be in to the setup.
References
[3] First drive of tube-balancing car,  http://goo.gl/6Kze1W
[4] HiTechnic HTWay Version 1.1, http://www.hitechnic.com/upload/786-HTWayC.nxc
[5] A PID Controller For Lego Mindstorms Robots, http://www.inpharmix.com/jps/PID_Controller_For_Lego_Mindstorms_Robots.html

Indsendt af kl. Ingen kommentarer:

torsdag den 15. maj 2014

Final project - Lesson 2

Date: 15/05 2014
Duration of activity: 08.15 - 13.00
Group members participating: Pætur Askildsen, Christian Jegstrup Hansen, Søren Gregersen, Søren Ditlev and Alexander Rasmussen
Changes from last time
Last session we found inspiration to different projects we could use as our end course project, and decided to go with the self balancing robot on a ball, ballbot, and also build a robot to drive inside the ball on which the other robot balances. The robot inside the ball can be remotely steered. Based on an internet search on ballbot projects we found that few had actually made a balancing ballbot, approximately 7 that worked [1]. And these projects made a ballbot, not extending the ballbot with a little robot inside the ball, as we wanted to. Therefore we concluded at the start of this session that while it looked like a very fun project to do, it was difficult to accomplish - not something that could be build within the time available for our end course project.
Therefore we have modified the project description so that the robot should not balance on a ball, but instead on a big tube with a diameter of 200-300 mm. This simplifies the balance challenge in the sense that instead of working with two axes (and two motors) we only work in one axis (with one motor), the axis in which the tube rolls. With this simplification the robot can also only fall in either direction along the tube-roll axis, where the ballbot can fall in either direction in a 360 degrees circle. With our tube project we can just use forward / backwards power to keep the robot from falling off the tube where in the ballbot project the power to the two motors controlling the 2 axes should be intelligently set so the robot raises from the direction in which the ballbot is falling.
      
Figure 1: Change from Ballbot project to tube-balancing robot project.
This reduces the number of challenges to overcome and the constants to be tweaked, which increases our chances to succeed with our end course project. The final robot will furthermore have some similarities to the SegWay robot we programmed earlier, thus enabling us to draw on our previous knowledge from lesson 5 [2].
Goal
To find information about projects similar to our balancing robot project and to lurk their tricks. Additionally also to build the first version of both the robot inside the tube and the balancing robot on top of the tube. For the robot inside the tube: begin experimenting with a remote controller. For the balancing robot on the tube: Test the gyro sensor with a LegWay robot since we do not have a tube yet.

Plan

  • Find the group from last year’s lab report which had a vision for a project similar to ours.
  • Find building instructions for a LegWay robot which uses the gyro sensor to start experimenting with the gyro sensor until we obtain a tube for our project.
  • Get the LegWay to balance.
  • Start programming a remote control, which will use bluetooth communication, which shall control the robot which drives inside the tube.
Results

Experiments with gyro sensor by building a LegWay robot

We found a guide to use the gyro sensor for a balancing robot from the company’s website which manufactures the gyro sensor, HiTechnic [3], but this only has some NXC code for balancing a robot with a gyro sensor, [4], which we started out translating into Java code so it can run on LeJOS, until we found out that a group from last year had already done this, so we used their code as a starting point [5]. This was also the group from last year who had a vision for a project similar to ours [6]. They had not only translated the code, but also incorporated a PID-controller into the code. We tried out their code and we managed to get the LegWay robot to balance for at least 30 seconds, see [7] or click here for link to video.


We will have to tweak the code and the parameters when we get ahold of a tube and build a robot which can balance on the tube.
Figure 2: Shows the self balancing LegWay robot
Figure 3: First version of the car that should drive inside the tube.

Building the car to drive inside the tube and the remote control

The first version of the car to drive inside the tube can be seen in figure 3. The goal was to build a car with a wheelbase as small as possible, so that it can drive in a tube as small as possible. To achieve this, we needed the wheels of the robot to cover every angle of the car, the result was a car with a wheelbase of 165 mm, meaning that we should find a tube with a diameter of at least 250 - 300 mm.


Last year a group made their own remote control and we used their code and build as inspiration to program and build our own remote control [5]. The car inside the tube shall only drive either forwards or backwards, so our remote control shall only have a lever to control the speed and the direction.


Figure 4: The LegWay is balancing.
Conclusion and Plan for next session(s)
We built a LegWay robot using HiTechnic’s gyro sensor and we were successful to get it to balance for at least 30 seconds. The code uses a PID controller on top of the 4 different parameters obtained from the gyroscope and tacho counter. In the next lesson we have hopefully obtained a tube, and we will need to tweak the code (and understand it thoroughly) to match it to our tube-balancing robot context. A part of this will also be to find out if we need all 4 parameters for our tube balancing robot.
References
[2] Lesson 5 where we programmed a LegWay,  http://teamnxtgen.blogspot.dk/2014/03/lesson-5.html
[3] HTWay – A Segway type robot,  http://www.hitechnic.com/blog/gyro-sensor/htway/
[4] NXC code for HTWay Version 1.1,  http://www.hitechnic.com/upload/786-HTWayC.nxc
[7] LegWay balancing for 30 seconds, http://goo.gl/e5iqqK


Indsendt af kl. Ingen kommentarer:

torsdag den 8. maj 2014

Final project - Lesson 1 Finding a project to work with

Date: 08/05 2014
Duration of activity: 10.15 - 14.30

Group members participating: Pætur Askildsen, Christian Jegstrup Hansen, Søren Gregersen, Søren Ditlev and Alexander Rasmussen
Goal
The purpose of this lab session is to make an initial effort to come up with a description of the end course project that our group wants to do.
Plan
  • Look at the list of projects, discuss the projects in the list of projects or consider new suggestions.
  • For each project proposal that we discuss we will consider the hardware/software platform needed, e.g. number of NXT's, program on a PC, sensors, actuators etc.
  • Furthermore, for each proposal figure out the overall software architecture and the software architecture on each component, e.g. a behaviour-based architecture on each NXT and a server architecture on a PC. Use the course literature as reference.
Results
Here follows a lists of projects considered and for each project: a short description of the project, the hardware/software platform to be used and the software architecture of each component. We will also try to point out the most difficult problems to be solved in each project.

Project proposal #1 - Self-balancing robot on 2 wheels, LegWay

Short description

A LegWay self-balancing 2-wheel robot which can be remotely controlled or/and can follow a line. Alternatively it could be controlled through coordinates send to the robot over bluetooth using the different interfaces and classes available in leJOS for localization and navigation.

Hardware / software platform to be used in the project

To build this project it would be obvious to use the robot build in lesson 5 where we managed to build a self balancing robot that could stand for minimum 3 minutes, link to video, using a PID-controller [12][13]. In lesson 5 we build the robot proposed by Philippe Hurbain [1] just modified with bigger wheels, and used the Java program written by Brian Bagnall [2] as a base for our balancing robot. In this self-balancing robot we used a light sensor to measure the position of the robot.
The robot from lesson 5 should be expanded with one additional light sensor if it should be able to follow a line, ideally two sensors to enhance the precision of the line following behavior. Using a gyroscope instead of a light sensor for balancing should also be tried.
If we want to control the robot through coordinates sent to the robot via bluetooth, we will have to implement bluetooth and use the leJOS navigation classes [3], specifically the Navigator.class. Relevant course literature will also here be [4], [5].  

The most difficult problem(s) to be solved in this project

There are several things that are difficult in this project.
1) To build and program a stable self balancing robot, that can handle a bit of interference.
2) To make the robot able to move using a remote control while the robot keep balancing.
3) If we use the light sensor ( to make the LegWay balance and/or follow a line), it will be difficult to cope with the oscillating light sensor values caused by the oscillating robot as it constantly tries to keep itself balancing, we are convinced that the light sensor values will change with varying distance to the same surface.

End product we expect to present at the end of the project period

We want at least to get the robot to balance for a long time, and since we have already done this, this shouldn’t be too much of a problem. The next step would be to get it to balance more stable. When we have a stable balanced robot, trying to make it move by adjusting parameters is the next move, either through Bluetooth-communication and a small GUI at first or using a lego/xbox/other controller. Next up would be to get the LegWay to follow a line. If we get all this done, a last addition to the project could be to get the robot to navigate a space using the different interfaces and classes available in leJOS for localization and navigation.

Project proposal #2 - Self-Balancing Robot on a Ball

Short description

A self-balancing robot on a ball. It could be extended to be controlled by a joystick / arrow keys on a keyboard. It could also be extended to do obstacle avoidance by using an ultrasonic sensor. Another possible extension is route navigation, like explained for the LegWay balancing robot above.

Hardware / software platform to be used in the project

In this project we use a ball for the robot to balance on. We will have to implement a PID controller, where the constants will be chosen remotely using bluetooth communication. We will have to use
  • Two NXT motors
  • Two light or color sensors, or two NXT HiTechnic gyroscopes (one for x and one for y axis, as they are single-axis gyroscopes).
  • A joystick.
  • NXT Ultrasonic sensor.
If we want to extend the project with route navigation, we will use the leJOS navigation classes [3], specifically the Navigator.class and possibly course literature [4], [5].  

The most difficult problem(s) to be solved in this project

The first problem here is obviously to make a robot that is able to balance steadily on a ball.
Another challenge  will be to make the ballbot keep its balance while the robot is moving, whether this is done because we want to control the ballbot by using a remote control, if we want to implement obstacle avoidance through ultrasonic sensor or whether we want to navigate the robot using leJOS navigation classes.

End product we expect to present at the end of the project period

We hope at least to be able to get the a ballbot balancing, and when we succeed in that we will try to make it move by using input from a controller e.g. a joystick. If get through this checkpoint, making the robot do obstacle avoidance by using an ultrasonic sensor can be the next step. Using leJOS navigation classes to navigate the robot will our last step.

Project proposal #3 - Rubik’s cube solver

Short description

Construct a robot that can solve a rubik’s cube similar to the robots presented in [6]. A lot of attempts to solve a Rubik’s cube using Lego Mindstorms has been made the last 10 years, which makes it a classic challenge worth trying out.

Hardware / software platform to be used in the project

For a basic rubik's cube solving robot like the Mindcuber [8], we will need three NXT motors: One to control the color sensor, one to rotate the cube vertically and the last one to rotate it horizontally. The color sensor is used to detect the colors. The robot uses an ultrasonic sensor to detect if there is a cube present in the holder.

The most difficult problem(s) to be solved in this project

Find a construction that is able to hold the Cube steady, turn it in omni directions, while being able to manipulate the cubes individual sides. Designing software that is able to use the color sensor to identify how the cube should be manipulate.
Another possible challenge is to build our own robot and not just use the building instructions and code available on Lego’s own site for the MindCuber, made by David Gilday [7][8].

End product we expect to present at the end of the project period

At least a rubik’s cube solving robot. When this is done reducing the time with which the robot can solve a rubik’s cube will be pursued.

Chosen project - Project proposal #2 - Self-Balancing Robot on a Ball with a remotely controlled robot driving inside the ball

The reason for the choice

The ballbot offers challenges that we think could be fun to explore, both construction wise and code wise. Another advantage is that if we manage to get a ballbot to balance, it can easily be extended with a remote controller, avoidance of objects or route navigation.
After a talk with Ole Caprani we also chose to expand the goal of this project to also incorporate a robot which should drive inside the ball which the ballbot balances on. This robot inside the robot should be the one to be remotely steered instead of the ballbot.

A more detailed description of the chosen project

After further investigation of the problem domain we found the following information, presented in the text and links below.

We will need two gyroscopes if we use the HiTechnic NXT gyroscope as they can only detect 1 axis each; it contains a single axis gyroscopic sensor that detects rotation and returns a value representing the number of degrees per second of rotation, deg/sec [9]. A blogpost [10] however advises to use other gyroscopes than the HiTechnic gyroscope:
“Some gyro sensors, like the Hitechnic gyro for example,  are seriously affected by changes in input voltage. As the NXT is battery powered this is a serious problem. Starting the motors of the NXT will result in a power drop and thus in a change in offset. There is a trick to avoid this if you have a sensor mux with an external power supply. Like this one from Mindsensors. In general I advise you to choose another gyro.”
Since others have build a Ballbout using HiTechnics gyroscopes, we however still chose to go with those [11].
References to guide our work include


We found that there are several problems that need to be solved. First the construction of a frame that is able to support the ball, balance and encompass a motor is complicated, however we have found build instructions to help in this process [11]. The most challenging part will be to get the ballbot robot to actually balance. To get the robot to balance, we will program a PID-controller for the robot [12][13].
Figure 1: The NXT Ballbot which we plan to build, [11].
Plan for work with the end course project
Firstly we have to figure out whether we should use a light ball or heavy big ball, what the advantages and disadvantages are with both of the possible solution. As described in the section about this project, our first challenge is to get the robot balancing on the chosen ball. If we succeed in doing so, we will also try to implement a steering mechanism for the robot inside the ball, using either a joystick, the arrow keys on the computer’s keyboard, or coding a remote controller ourselves using bluetooth connection between two NXT’s making us able to drive the robot around in an arena like a circus clown on a one wheeled bike.


The sub-tasks to be done are:
  • Making a little robot balance on a ball like in [11], using a PID-controller.
    • Maybe try out different robot builds, ball sizes or ball weights.
  • Building a little robot to be inside the ball on which the robot balances, which can be remotely steered.
  • Thinking the 2 robots into a concept, e.g. to be presented on a conference stand. What would be fun for attendants to see / do?
References
[1] Philippe Hurbain, NXTway
[2] Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 11, 243 - 284.
The chapter contains a java program Sejway.java that can be used as a starting point for experiments with a self-balancing LEGO robot.
[4]  Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.297 - p.298.
[5], Java Robotics Tutorials, the ch. Enabling Your Robot to Keep Track of its Position. We could also look into ch. Programming Your Robot to Navigate to see how an alternative to the leJOS classes could be implemented.
[6] Videos of robots that solve a Rubik’s Cube, http://www.mindcuber.com
[7] Building instructions and code for the Rubik’s Cube Solver made by David Gilday: http://www.lego.com/en-gb/mindstorms/news/2012/april/have-your-own-robot-solve-a-rubiks-cube
[8] The MindCuber robot, http://www.mindcuber.com/mindcuber/mindcuber.html
[11] NXT Ballbot (Self-Balancing Robot On A Ball) Controller Design, Ballbot, Download including building instructions
[12] PID controller, wikipedia, http://en.wikipedia.org/wiki/PID_controller
[13] A PID Controller For Lego Mindstorms Robots, http://www.inpharmix.com/jps/PID_Controller_For_Lego_Mindstorms_Robots.html


Indsendt af kl. Ingen kommentarer:
Abonner på: Opslag (Atom)