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:

tirsdag den 6. maj 2014

Lesson 10 - Sumo Wrestling Robot

Date: 1. maj 2014
Duration of activity: 10.00 - 15.15
Group members participating: Christian Hansen, Pætur Askildsen, Søren Gregersen

Goal: To build a LEGO Sumo wrestler that can beat out the other robots in the wrestling arena.

Plan:
In this lab session we will construct and program a sumo wrestling LEGO robot and at the end of the lab session the sumo wrestling LEGO robots will fight against each other in a sumo arena as described in Figure 1.The sumo wrestling robots driving base should be based on the ideas in Express bot, a fotobased building instructions for a base car with extensions. A simple LEGO sumo wrestler can e.g. be build as follows (click on the image to see details):
Figure 1: Two LEGO robots are ready to start a wrestling fight. The fight ends when the losing robot is pushed out of the arena or is overturned. If this does not happen in 2 minutes the fight ends as a draw.

The sumo robot should be programmed by means of the behavior-based control paradigm, [2].
Before we program the sumo robot we will investigate how a behavior-based architecture, [1], has been implemented in the subsumption API of leJOS NXJ. Especially, we will investigate the interfacelejos.subsumption.Behavior and the class lejos.subsumption.Arbitrator and try to make an alternative implementation of the Arbitrator.

BumperCar

As an example of a behavior-based control program the leJOS NXJ distribution contains a BumperCar program in the folder samples/BumperCar. It consists of two behaviors DriveForward and DetectWall both implementing the interface Behavior and a main program BumperCar that uses an instance of the class Arbitrator to control the activation of the two behaviors.
First, make BumperCar run the base sumo wrestler driving base mounted with a bumper and an ultrasonic sensor.
Then make the following experiments with the BumperCar to investigate the functions of the Arbitrator:
Press the touch sensor and keep it pressed. What happens?
When the touch sensor is kept pressed, the method action in the detectWall class is continuously repeated. This means that the car drives backwards for a short moment and thereafter turns slightly left. In the code this is:
BumperCar.leftMotor.rotate(-180, true);
BumperCar.rightMotor.rotate(-360);
Implement a third behavior, Exit. This behavior should react to the ESCAPE button and call System.Exit(0) if ESCAPE is pressed. Exit should be the highest priority behavior. Try to press ESCAPE both when DriveForward is active and when DetectWall is active. Is the Exit behavior activated immediately?
When DriveForward is active, the Exit behavior is called instantly when the Escape button is pressed. So at any time, we are able to interrupt the program by pressing the Escape button. But when DetectWall is active, the Exit behavior cannot be activated by pressing the escape button when the program is in the middle of a loop. It is only possible to interrupt the DetectWall with the Exit behavior when the escape button is pressed immediately after the cycle described in the previous exercise has finished, that is just after the right motor has stopped rotating. This is because the BumperCar.rightMotor.rotate(-360); is a blocking method. It can be replaced by BumperCar.rightMotor.rotate(-360, true) to make the method return immediately.
Both DriveForward and DetectWall have a method takeControl that are called in the Arbitrator. Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called when the triggering condition of DetectWall is true.
takeControl of DriveForward is not called when the triggering condition of DetectWall is true since DetectWall has a higher priority than DriveForward. This can be seen in the Monitor thread in figure 2, where it runs through the behavior[] ArrayList from the largest index/priority and downwards, and if takeControl of a behavior at a index returns true, that behavior is set as the highestPriority and the for-loop breaks. So if a higher-priority behavior’s takeControl method returns true, a lower priority behavior’s takeControl method is not called.
Figure 2: Excerpt from the Monitor thread. This shows that takeControl of DriveForward is not called when the triggering condition of DetectWall is true, since DetectWall has a higher priority than DriveForward.
The takeControl method of DetectWall contains a call to the ultrasonic sensor method getDistance that includes a delay. This means that the call of takeControl for the other behaviors is delayed and the reaction to an event is not immidiate. In [1] it is recommended that takeControl "should return quickly, not perform a long calculation." To avoid the pause in the takeControl method of DetectWall a local thread in DetectWall could be implemented that sample the ultrasonic sensor e.g. every 20 msec and stores the result in a variable distance accessible to takeControl. Try that. For some behaviors the triggering condition depends on sensors sampled with a constant sample interval. E.g. a behavior that remembers sensor readings or sum a running average. Therefore, it might be a good idea to have a local thread to do the continuous sampling.
We tried to continously sample the UltraSonic sensor readings in a local thread, making the DetectWall behavior as follows in figure 3, where a while(true) loop runs continuously updating the sonarDistance variable almost as often as possible with a sleep delay of 5 ms. We chose the 5 ms because the sonar.getDistance already takes some while to find a distance:
public int getDistance()
Return distance to an object. To ensure that the data returned is valid this method may have to wait a short while for the distance data to become available.
so that hopefully we will get a sample approximately every 20 msec, but we don’t know what the exact time the of the getDistance method to return is. We could have made tests to find the average time the getDistance method takes to return a distance to be able to specify a more correct sampleTime, but we choose to be satisfied with a guess because of time considerations.
Figure 3: The DetectWall behavior now samples the sonarDistance in a local thread to make DetectWall’s takeControl return as immediate as possible.


Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.
We did this by adding a few lines of code to the DetectWall action() method:
Figure 4: The DetectWall behavior actions now go backwards for 1 sec before turning.
But this made the car not go straight backwards when the DetectWall action() was called immediately as it first rotated a little counterclock-wise. We think this is because the BumperCar sample code uses RegulatedMotors instead of MotorPort motor controls, and therefore it runs a little while backwards with only the leftMotor.backward() command active before rightMotor.backward() is started, cf. Figure 4.
Try to implement the behavior DetectWall so it can be interrupted and started again e.g. if the touch sensor is pressed again while turning.
This behaviour was not implemented, but we had a good talk about the reason for implementing this behavior. If the surroundings are static and the manoeuvre for avoiding the object only consist of a backwards driving and a turn, it does not make sense to take care of another push on the button.
But if the surroundings are not static (e.g. robots driving around on a track) or the avoidance manoeuvre also consists of a forward driving with the risk of bumping into objects or other robots while performing the action, it would make sense to implement it.
One thing to always be aware of though is that if this behavior is not implemented, the robot is “deaf” and “blind” to it’s surroundings while performing the avoidance manoeuvres.   

Motivation Functions

When the DetectWall behavior is active another hit on the touch sensor will not reactivate the action sequence in the method action. It makes of course no sense to reactivate action as long as touch is pressed but what if it is pressed again while it is turning? Lets consider how Thiemo Krink's motivation functions, [2], can be used to make such a reactivation possible.
First change the interface Behavior so takeControl returns a motivation value. e.g. an integer value. The behavior with the highest motivation value should then be activated each time through the loop in the Arbitrator.
Second, implement a new Arbitrator that does this.
Third, change the BumberCar behaviors DriveForward, DetectWall and Exit so takeControl returns motivation values. Especially, how could takeControl be programmed to give high values when touch is pressed and lower values when it is ok to reactivate the action method ?
In Behavior.java, Arbitrator.java and BumperCar.java there are files that show how it can be done.
We did not have time to code this ourselves, but we have investigated the classes Behavior.java, Arbitrator.java and BumperCar.java to see how it may be done.

A Behavior-based Control Program for the Sumo Wrestler Robot

Use the behavior-based control paradigm, [2], to program the sumo wrestling robot. As a basis for the implementation use either the leJOS behavior-based architecture, [1], or use the classes with the modifications described above.
The rules for a sumo robot is as follows:
  • The sumo wrestling robots driving base should be based on the ideas in Express bot, a fotobased building instructions for a base car with extensions.
  • Only LEGO elements can be used in a LEGO sumo robot.
  • The weight of a sumo robot must be less that 1 kilo. The floor extension should be within 30 cm x 30 cm.
  • A sumo robot has to be autonomous.
  • After a press on a start button the sumo robot should wait 3 seconds before it begins.
We used a defensive strategy: Our Sumo Wrestler Robot just turned the footlights of the light sensors on and just stood still, hoping that the other wrestler would drive off the track.
We fought against two opponents which we could keep up with, meaning we had 1 point in both matches. Our car stood rock solid even though the other cars used all their power to push our car off the track. After one minute the opponent realized that our car was not going to move at all, and they wanted to call a tie to save battery for their next race.

We used this defensive strategy because, in the time available, we could not get our intended behaviours to work. We wanted to implement three behaviours, inserted in a Behavior arraylist as follows:
  1. Stand still (standard)
  2. Attack (if bumper is pressed)
  3. Avoid (if light sensor detect white)
If the sensors did not detect anything, the car should just stand still.
We equipped the car with two light sensors, one in the front and one in the back. If the front light sensor detected white, the car would drive backwards and if the rear light sensor detected white, the car would drive forward.
In the front of the car we mounted two bump sensors, which were connected to a ramp which should work in the same way as a snowplow does: it would reject the opponents attempt to throw our robot of the arena but also try to push the other robots out of the arena.
Conclusion:
We got 2 points in the preliminary sumo wrestling robot round (2 ties), and we are satisfied with that result.
References:
[2], Jones, Flynn, and Seiger, "Mobile Robots, Inspiration to Implementation", Second Edition, 1999.

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