Changes between Version 21 and Version 22 of Old/Dailyupdates

Timestamp:

Jun 14, 2007, 11:25:37 PM (17 years ago)

Author:

aniket

Comment:

—

Old/Dailyupdates

@@ -109 +109 @@
 == 6/12/07 - Day 7 ==
 
-Image ghosting was successful. Not only did we make a duplicate of Mobile 33 onto Mobile 37, we also made a third copy on our recently aquired Mobile 40. For now I will refer to each robot by the fictional robot on its KDE wallpaper, so Mobile 33 = Terminator, Mobile 37 = Bender, and Mobile 40 = Artoo. Maybe we'll come up for better names for them soon.
+Image ghosting was successful. Not only did we make a duplicate of Mobile 33 onto Mobile 37, we also made a third copy on our recently acquired Mobile 40. For now I will refer to each robot by the fictional robot on its KDE wallpaper, so Mobile 33 = Terminator, Mobile 37 = Bender, and Mobile 40 = Artoo. Maybe we'll come up for better names for them soon.
 
-We had some success calibrating the Terminator's camera with ''calibrate_camera_intrinsic''. The best place we found to do it was the lobby right next to the yellow doors of Winlab, where the light is dim and non-flourescent. We intend to complete the now mundane task of calibrating the remaining two cameras soon.
+We had some success calibrating the Terminator's camera with ''calibrate_camera_intrinsic''. The best place we found to do it was the lobby right next to the yellow doors of Winlab, where the light is dim and non-fluorescent. We intend to complete the now mundane task of calibrating the remaining two cameras soon.
 
 We accidentally ripped one of the chords that connects the battery to the motors today. This was an unfortunate setback, and it took up some time to solder new connectors together.
@@ -127 +127 @@
 A potentially serious problem we've realized is that the navigation tool is not remembering any landmarks. This is a big problem because landmarks are the way the robots remember obstacles they've encountered in a room and build a map of their surroundings. Originally it was thought that lack of calibration was the problem, but having calibrated the robots we find that at least Bender still does not catalog any landmarks in Navtool. I now suspect the culprit may be a broken communication link between the vSlam applet and the camera. An error in the logs warns us to check permissions on /dev/video0, which are set to 666 as I believe they should be.
 
-Today, magically, the teleop applet was working with camera support on Bender. When we clicked a destination for the robot, it moved in generally the right direction, but passed the target and spent a long time colliding into the wall until we swithed off the battery. This is dissapointing, especially considering that the camera is supposed to be calibrated.
+Today, magically, the teleop applet was working with camera support on Bender. When we clicked a destination for the robot, it moved in generally the right direction, but passed the target and spent a long time colliding into the wall until we switched off the battery. This is disappointing, especially considering that the camera is supposed to be calibrated.
 
 This afternoon I figured out the landmarks problem. The very simple solution: run ''run_slam_explore'' before ever running ''run_client_gui''. The theory: When we first started playing with navtool, we realized that if we started the server first, we did not see any video on the side panel labeled "camera local." We took this lack of video to mean that things were not working properly, and soon discovered that if the client was launched first and the server second, the video appeared. What we didn't understand was that whichever program is launched first hijacks the camera and prevents the other from accessing it. Therefore; when we launch the client first, we see the video, but the slam server cannot take pictures and therefore cannot create landmarks. However, if the server is launched first, we cannot see the video but the slam server can take pictures and can and does create landmarks. Now, when I run the client, if I see the video right away I know something is wrong. (Often times I forgot to turn on the battery).
@@ -133 +133 @@
 I spent part of the afternoon reassembling the chassis for Artoo. The previous design was pretty abysmal; there was no place for the motor battery and the labtop couldn't even sit on it unless it was partially closed. I reworked it to solve those two problems, but I fear that the motors might be installed backwards as well. I'm not sure if this is the case, but we'll check it out early tomorrow and resolve the issue if it is one.
 
+== 6/14/07 - Day 9 ==
+
+As it stands, only Bender is fully operational. Artoo's chassis is looking good, but for some reason the robot still refuses to make landmarks. When on explore mode in Navtool, it moves in a peculiar pattern that made us wonder if there was something wrong with the left motor so as to make it sluggish. The robot tends to travel in a curved path. However, using a python script (triangles.py) we found that the robot is quite capable of moving in a straight line. I suspect that the lack of landmarks is a result of this erratic movement rather than any disconnection between the software and the camera; I remember reading somewhere in the guide that it is difficult for the robot to create landmarks while moving along curved paths. (This is by no means certain)
+
+The thing keeping the terminator from working for now is that the camera is unmounted. We need some epoxy to mount the camera and then we will test it's navigation system. 
+
+We learned how to calibrate the IR sensors today. The task involves measuring the position of the sensors with respect to the coordinate system of the robot, which is defined as follows: The origin is located on the floor directly between the two back wheels and directly below their common axis. Positive X is the forward direction of the robot, positive Y is leftwards, and positive Z is up. The parameters Roll, pitch, and yaw are angles defined as rotations about the axes X, Y, and Z respectively. To calibrate the IR sensors, all we need to do is measure these 6 quantities (position and rotation) and declare them in the file ''resources-config.xml''.
+
+We turned our full attention to the Tutorials Guide for the first time today. The first tutorial, 01-simple, is a code that makes the robot move a given distance forward, take a picture, and display the picture momentarily. We got the code to make the robot move and snap a picture, but code creating the GUI picture display refused to compile. The compiler complains about the type ''!IImageWindow'' being undefined, although the !API indicates that it is a class in the Evolution namespace. We will investigate this more tomorrow.
+
+It took quite a while before I felt like I understood this first bit of code. The programming is very high level, and many objects need to be created for apparently elusive reasons. For example, one method takes two arguments. Before these arguments can be passed to the method, they must be stored in a !TaskArgs object. To complicate things further, one of the arguments is a !DoubleArray. A !DoubleArray is an array of doubles but stored in an object defined by Evolution. Rather than simply creating an array of doubles, we need to create an array of doubles and pass it as an argument to a new !DoubleArray object. This instance of !DoubleArray is then passed to !TaskArgs which in turn gets passed to a new !TaskContextPtr, which is a sort of smart pointer containing the data needed to execute a task. To execute a method, we must pass the result of a !TaskContextPtr's get() method to a task functor's run() method. The whole process seems a bit convoluted, but we're hopeful that we'll be able to accept it and use it.
+
+I read ahead a bit in the tutorials guide. Among the many features Evolution provides is an object which handles the processing of multiple tasks simultaneously. This will certainly come in handy when we write our own code.
+
+We've gotten a few suggestions for code we should write, and I think we should get started on it soon. First off, I would very much like to see obstacle avoidance working with our code, as I feel it is in many ways fundamental if the robots are ever to be useful in Winlab. Once this is figured out, (on Ivan's suggestion), we should write some code that makes the robots move about basically randomly (except for obstacle avoidance). Additionally, I would like to make some robust and easy to use !MoveToCoordinate type commands which through SSH or whatever other means will cause the robots to create design a smart path and travel to a desired location. With these goals accomplished reliably, we'll be able to start using the robots to study wireless communication.