Personal tools
You are here: Home Teaching 2006 SIPHER Group Pages Controlling Robots
Document Actions

Controlling Robots

Students will use a Max232 to adapt a Lego Mindstorms robot to use bluetooth communication, then using java, will have the robot explore a maze, communicate the layout of the maze back to a computer, then build a controller to allow the robot to be driven from the computer screen.

8/04/06(Fri)  End of SIPHER

  • Gave final presentation, turned in report, and preformed a demostration of our project

8/03/06(Thu)

  • Continued with review of final report, presentation, and poster
  • Practiced presentation

8/02/06(Wed)

  • Made revisions to the final report, presentation, and poster
  • Circuit was altered and know works, but the transmitting has errors in it.   Excess noise sent through the serial port causes errors in the DLL's ability to receive information accurately.

8/01/06(Tue)

  • Continued working on the final report, presentation, and poster
  • Experimented with the circuit

7/31/06(Mon)

  • Continued work on final report
  • Began work on project poster
  • Began to work on commenting program files

7/28/06(Fri)

  • Continued work on the power point presentation
  • Began work on final report
  • Repaired the RCX bricks

7/27/06(Thu)

  • Tested various maze layouts to determine if the algorithm functions correctly for each case. Discovered a minor flaw where the computer would not consider the surrounding area of a previously visited block. If a zero, or unvisited block, was reachable from the two, or visited block, the computer would ignore it and move on from there, usually resulting in the remainder of the maze being reset as walls.
  • Created print out displays with instructions that informs the user of an error in their selection, when a move has been completed, or when it is appropriate for them to select a point.
  • Began work on final presentation power point.
  • All three RCX bricks have been rendered inoperable for the time being.

7/26/06(Wed)

  • Continued modifying the class, ExploreTest. The tests for this program have/ accurate results for some trials and inaccurate for others. This leads me to speculate that 100% accuracy for the movements of the robot with the current wheels are impossible.
  • Created the class, ExploreNWTest, that contains the explore method that will be downloaded to the robot. The difference between this program and ExploreTest is that this program uses the dimensions of the robot as it runs on gears (I removed the wheels). Results are reasonable.
  • Troubleshooted the RCX hardware. Both RCX bricks that have had soldered alterations are not functioning properly.
  • Reviewed RobotLejos class. This will be modified to contain more accurate movement methods.


7/25/06(Tue)

  • Continued modifying the class, ExploreTest, that contains the explore method that will be downloaded to the robot and called from the pc.
  • Tested the Bluetooth circuit with the RCX brick (running a program that can activate the motors based on the input it receives).
  • Troubleshooted the RCX hardware. There was a lot of problems downloading programs to the robot.
  • Troubleshooted the Bluetooth circuit.  Calibrating the circuit to give accurate output was a challenging task and depends on a number of factors.


7/19/06(Wed)

  • Continued modifying the class, ExploreTest, that contains the explore method that will be downloaded to the robot and called from the pc.
  • Discovered a flaw in the RotationNavigator class (from the lejos api). The travel method cannot be interrupted by the stop() method once it has started. Therefore, we cannot use the travel method for our explore algorithm.
  • Researched the recurring problem of the firmware being deleted. It could be that the programs we are downloading use up too much memory. The size of the files we have been downloading don't exceed 7K (well below the 12k maximum).


7/18/06(Tue)

  • Implemented a check where once the computer receives a command from the robot it immediately returns it back to the robot, where it will be compared to the original sent message. However, there were some issues with the checking. So, in order to test the byte operations, the error checking was commented out until further corrections can be made.
  • Began error testing with the maze exploration and go to point algorithms.  If the robot is trapped by walls, neither of the two algorithms should continue working on a way to reach those locations. Upon testing this, we discovered that possibility was not being handled. So, a makeWalls method was created where if the robot is surround by walls the remainder of the maze will be set as a wall, thus preventing the program from trying to access these locations.
  • Also tested the maze mapping on a large 10x10 maze.  The final solution was correct, but its processing was slightly different as we have coded in what directions of travel are more favored than others.  At one point in the maze there is a left turn opening, but the “robot” continues to travel forward, because forward and right turns are the favored directions of travel.  At the end of the mapping, the “robot” had to make this big circle to reach the previously ignored opening. But in the end, the computer side result matched the hard coded robot side maze.

7/17/06(Mon)

  • Completed the conversion of string movement commands to byte operation commands
  • Completed error checking on information sent from the robot to the computer
  • Converted the dll to sent and receive byte rather than the previous string commands
  • Discovered that scrolling up in the command line window while the process is running cause a back up in the communication port resulting in the information becoming one long continuous string instead of true, false, or test alone.

7/14/06(Fri)

  • Began to convert string movement commands into byte operation commands
  • Also, began to create error checking on information sent from the robot to the computer, as the data may be altered during its transfer from one to the other.
  • Continued testing on the robot once again to determine how to complete accurate turns. Through trial and error with the input dimensions of the RotationNavigator class, the robot's turns are almost sufficiently accurate.
  • Began writing a class, ExploreTest, that contains the explore method that will be downloaded to the robot and called from the pc. This class also has a sensor listener that transmits the value of the touch sensor.
  • Upon testing ExploreTest.java, the robot's firmware was erased and could not be re-downloaded.

7/13/06(Thu) NASA Trip

7/12/06(Wed)

  • Corrected the problem with one dll having control over the comm port and not releasing when the next dll started.
  • Researched the possibility of having one dll for multiple files, but were unable to locate any descriptions on how to.
  • Attempted to have the dll native methods as public static methods located in one file, but were unable to run this way as it resulted in a hotspot error.
  • Began adding ways to control when the user can select a point in the maze for the robot to travel to and added a dialog to inform the user when they could select another point.
  • Also began to construct byte operations and error checks.
  • Began testing on the robot once again to determine how to complete accurate turns.
  • Continued modifying the RobotReader class to improve the efficiency. First attempts at doing this have failed.

7/11/06(Tue)

  • Corrected the logical error that exsisted in the go to point algorithm.
  • Began simulation using both the maze mapping and go to point algorithm. During this process, discovered that the dll needs to include a close method so that each file releases it hold on the communication port, so that the next process can gain access to it.

7/10/06(Mon)

  • Created a program to test the robot's ability to receive instructions from the comptuer.  A wire had disconnected form the serial port of the Bluetooth device connected to the robot causing it not to receive any communication from the computer. Once the wire was reconnected, the robot accurately received the information from the computer
  • Discovered a problem with the go to point algorithm, spent remainder of day in search of the cause and a solution.

7/07/06(Fri)

  • Continued optimizing code by separating lines of code in RobotReader class to separate methods.
  • Tested the Bluetooth circuit that will be used on the robot by linking it to the computer. The circuit generated values and transmitted it to the computer's serial port. The output was displayed on the hyperterminal.
  • Tested a java program that communicated commands to the robot via the bluetooth circuit. This was unsuccessful.
  • After troubleshooting the circuit, we discovered that the accuracy of the output was dependant upon the voltage from the battery and the resistance of the potentiometer.

7/06/06(Thu)

  • Abstracted the go to point algorithm into RobotMovement.java
  • Optimized the RobotMovement class to have a max of 40 lines per method (readability and efficieny issues)

7/05/06(Wed)

  • Continued to correct timing problems that existed in the simulation
  • Maze mapping worked without errors.  MazeFrame is able to draw the maze as it is being created and where the robot is currently located
  • The go to point simulation had some errors in premitting the user to click another location in the maze to travel to after the first one is completed.  Also, it did not display the maze as the process was being completed as with the maze mapping simulation.

7/03/06 - 7/04/06 (Mon-Tue) Fourth of July Holiday Break

6/30/06(Fri)

  • Gave mid-summer presenation on own progress for the first half of this summer program

6/29/06(Thu)

  • Revised and updated the power point presentation and mid-summer report
  • Practice for presentation on our own, then as a group

6/28/06(Wed)

  • Completed the computer side controller for the robot-computer simulation
  • Updated the report to match the template provided
  • Successfully simulated the interaction between the robot and computer. Although several errors occurred due to timing problems
  • Continued work on the power point presentation

6/27/06(Tue)

  • Completed developement of the algorithm to get the robot to a particular point the maze.
  • Continued to work on the computer side controller for the robot-computer simulation using the bluetooth brain boxes
  • Completed graphical representation of the maze so that a user can click on any point in the frame that is acceptible for the robot to travel to
  • Continued on the power point presentation for the mid-summer report

6/26/06(Mon)

  • Completed writting the mid-summer report with LaTex.  All that remains is for it to be checked for spelling and grammar errors
  • Continued working on the computer side simulator and its associated algorithms
  • Began to revise the graphical presentation of the maze so that an area may be clicked and the robot will know where in the maze to travel
  • Continued developement of the algorithm to get the robot to a particular point the maze.

6/23/06(Fri)

  • Continued developement of the algorithm to get the robot to a particular point the maze. 
  • Continued to work on the computer side controller for the robot-computer simulation using the bluetooth brain boxes
  • Watched a hawk eat a squirrel on the way back from Ethan's presentation on creating a formal foundation for domain specific modeling languages
  • Made modifications to the algorithm that lets the robot explore the maze, discovered that the algorithm will loop in a discovered area because it can not determine the necessary turns to get to a reachable zero

6/22/06(Thur)

  • Developed flow chart that determines how to get the robot to a particular
    point in the maze (autonomously).
  • Started to create a method that implements the flow chart stated above.
  • Began writing the code to simulate the robot so we can test the rest of
    our code without having to download anything to the robot.


6/21/06(Wed)

  • Used JNI to import a C function into Java that writes a received string to the serial port. This serial port was connected to an adjacent computer's serial port via bluetooth so the output of the program appeared in the adjacent computer's hyperterminal.
  • Used JNI to import a C function into Java that receives string from the serial port and prints it out on the screen. This serial port was connected to an adjacent computer's serial port via bluetooth so the output of the program was the input from the adjacent computer's hyperterminal.
  • Continued to write the mid-summer report in LaTex
  • Continued to create the PowerPoint presentation of the project's progression for the mid-summer presentation
  • Began writing an interface for a class that would simulate the robot in terms of responses and sensor output.


6/20/06(Tue)

  • Continued with the experimenting with the creation of .dll files
  • Began to create PowerPoint presentation of the project's progression for the mid-summer presentation
  • Also started to write the mid-summer report in LaTex
  • Continued hyperterminal link communications between the two computers using the .dll files we created
  • Modified and tested the Maze and MazeInterpreter classes. The maze can now fully search through the maze for a solution, turn around, and find another solution.
  • Used JNI to import a C function into Java that writes a received string to the screen.

6/19/06(Mon)

  • Began experimenting with the creation of .dll files in order to learn how they work and how to efficiently created.
  • Set up bluetooth Brain Boxes on two computers, one which will act as the server and the other which will act as the client.  With these devices, we will practice using the communication capabilities of a bluetooth network.  The two devices are connected to the computers using serial connections on the back of the computers.
  • Set up communication of the two devices using hyperterminals.
  • Made further modifications to the Maze and MazeInterpreter classes.

6/16/06(Fri)

  • Viewed presentation about the sniper detection and weapons classification based on the blast frequencies in order to determine from which weapon and location it was fired
  • Wrote and tested MazeFrame.java, which is a file that creates a graphical representation of the maze layout.  Using the following color scale, the class displays the layout of the maze on the screen: black represents walls, white represents undiscovered areas in the maze, and blue represents the discovered areas of the maze.  With further coding, this class should be able to display the maze as the robot returns information about it back to the computer. However, the class may need to be condensed into a few methods and place in the Maze class file, in order for this to occur.
  • Continued modification and testing of the MazeInterpreter class. The goal is to have this class working together with the Maze class in an efficient and cleanly coded way. Unsuccessful thus far.

6/15/06(Thu)

  • Wrote and tested LocationTest.java in hopes of finding an alternative to rotating the robot, as the rotations are not always accurate.  However, the RotationNavigator API's gotoPoint(x,y) use rotations to steer the robot to a given point, so this option was rejected as well.
  • Began to study how to create our own DLL, which will be used in the communication from robot to computer.
  • Added to and corrected some of the methods in the Maze class and SolutionTestWithArray.java
  • Tested the SolutionTest.java program on the robot. The program performed successfully although the angle accuracy on the robot is still off. This is a problem that will be addressed later.
  • Wrote and tested the MazeInterpreter.java program. This program is similar to SolutionTestWithArray.java except it also allows the robot to go backward and search for new ways to complete the maze.

6/14/06(Wed)

  • Continued to add information and implement changes to the "Maze" class inorder to allow for better maze traversal
  • Purchased and laid posterboard onto the maze in order to provide a surface that allowed the robot to turn easier.
  • Modified the robot to lower the center of mass (less weight going directly on the wheels) and changed the two front wheels for more accurate rotations.
     Implemented previous test files on the modified robot to determine if the changes would affect any of it processes
  • Wrote and tested the program SolutionTest.java. This program sends the robot through the solution path of the maze (assuming the solution path is already known).
  • Wrote and tested the program SolutionTestWithArray.java. This program uses an array to determine what direction it will go. The array is the correct solution for the maze.

6/13/06 (Tue)

  • Revised the flow chart for determining direction in order to make the algorithm run until it receives a signal to end.

  • Wrote program ToRobot.java. This implements the flow chart mentioned above. It instantiates a maze class, tells the robot to explore the walls around it's current square, tells the robot to rotate to the closest opening (in the clockwise direction), moves forward one square, and then updates the grid coordinates.
  • Created "Maze" class. This contains all of the methods and variables associated with the maze. It holds the dimensions of the maze with a coordinate system for each block of the maze.
  • Reviewed the "josx.rcxcomm" package. This is a package for communication between a PC and the RCX. It is important information if we are to figure out how to connect the robot via bluetooth.
  • Tested (unsuccessfully) one of the rcxcomm examples that came with the lejos software. The program was supposed to make the RCX send the value "123" to the computer but we received an error while trying to run it. The RCX program compiled and downloading ok and the PC program compiled ok. However, when we tried to run the PC program we received an "UnsatisfiedLinkError".


6/12/06 (Mon)

  • Discovered that the surface on which the robot is performing is a factor in the inaccurate rotations.
  • Layed out a simple maze that was used to begin the formation of the maze traversal algorithm and to clarify some indecisions about the necessary operation of the robot
  • Wrote and tested MovementTest.java, which moved the robot forward two units of distance in the maze, stopped the robot, then moved it forward enough to touch the maze wall.  The touch sensor was then tested to prove that the bump into the wall was sufficient enough to trigger the sensor
  • Wrote and tested TurnTest.java, which tested the angles that are necessary for the robot to perform semi-correct rotations for left and right turns on a surface of poster board, which was determine to thus far be the best surface for the robot
  • Wrote and tested CubeTest.java, which moved the robot in the square testing for wall locations for the maze traversal.
  • Created flow charts to analyze the necessary step involved in many of the algorithm processes.
  • Discussed in detail how to implement the algorithm processes.

6/09/06 (Fri)

  • We rebuilt the robot so the new changes in the loaction of the rotation sensor matched the rest of the robot.
  • We developed preliminary pseudocode for possible ways to get the robot to go through the maze and communicate to the computer where the maze walls are located.
  • We removed the wheels from the robot and (while testing  with the RotationNavigator class) discovered that the robot rotates with greater accuracy when running on gears (no wheels). We inferred that the problem with rotation was mainly due to wheel/surface interaction.

 

6/08/06 (Thu)

  • We realized that the inpreciseness of the robot's rotation was caused by the unpredictable movements of the free front wheels (originally, the motors were only connected to the back wheels). So we redesigned the robot to have the motors connected to both the front ant the back wheels. This showed considerable improvement when we tested the robot with "RotateTest".
  • Wrote and tested the class SensorTest.java. This program was used to display the rotation sensor readings on the LCD screen from a particular motor. This was helpful because we noticed that the new design had the sensors reading backwards.
  • We reversed the orientation of the motors (which of course caused the forward signal to make the robot go backwards) because of the sensor issue stated above.  We will modify the location of the touch sensor tomorrow to correspond with these changes.
  • Tested the previously written classes: RCXTest5.java, RotationNavigator.java, RatioTest.java, RotateTest.java

6/07/06 (Wed)

  • Wrote and tested the class RotateTest. java. This program was used to determine if we could successfully rotate the robot clockwise and counterclockwise for 10 seconds each. It was successful.
  • Wrote and tested the class RatioTest. java. This program was used to determine ratio of the sensor rotation to the wheel rotation (needed for RotationNavigator class). We measured the amount the wheel turned for a duration of 16 sensor units (one full revolution).
  • Wrote and tested the class RotationNavigatorTest. java. This program was used to determine if the pre-written class RotationNavigator worked. The "travel" method (robot travels a given distance) worked succesfully. However, the "rotate" method rotated only half the amount specified. Also, the two motors did not rotate with the same precision. We infer that motor C is weaker than motor A.
  • Wrote and tested the class SquareTest. java. This program was used to determine if the RotationNavigator class would help the robot move in a square. As expected, it was unsuccesful because the two motors did not rotate with the same precision.
  • Tested different power settings for the motors to see if it affected the robot's ability to move in a straight line.

6/06/06 (Tue)

  • Added a second rotation sensor so that both motors are monitored during travel.
  • Tried numerous methods to get the robot to move in a straight line.
  • Reviewed information on Java Threads.
  • Discussed Java Threads with Daniel and followed his demonstration.


6/05/06 (Mon)

  • Updated our lego robot to have a differential gear and a rotation sensor which would allow the robot to travel in straight line
  • Created and tested a program to determine if the robot could travel in a straight line
  • Made alterations to robot and program in pursuit of straight line travel

6/02/06 (Fri)

  • Continued with GME training
  • Discussed "Models of Computation" paper and Chapter 1 of "Embedded Systems Design" book with Daniel
  • Developed a UML model of a bicycle with Daniel
  • Viewed presentation on Improving Robot Control with Human Factors
  • Started building lego robot
  • Tested a java program to move the robot for 10 seconds and beep


6/01/06 (Thu)

  • Continued GME training with Ethan
  • Began LaTex training with Daniel

5/31/06 (Wed) 

  • Continued GME training with Ethan
  • Introduction into the summer project with Daniel

5/30/06 (Tue)

  • Introduction into the SIPHER program
  • Tour of ISIS and SIPHER labs
  • Began GME training
  • Received two papers on embedded systems and models of computation
« November 2009 »
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
 

Powered by Plone, the Open Source Content Management System

This site conforms to the following standards: