Abstract
Using the new TI eZ430-Chronos sport development watch, which is based on the CC430, we created an electronic door unlock device. The watch communicates wirelessly to lock and unlock the door after given a secret password (a sequence of taps on the watch’s 3-axis accelerometer). This system demonstrates an ultra-low power consumption wireless system using TI’s MSP430 architecture, achieving estimated battery lifetimes of over 4 years on the watch and over a year on the door.

Hardware
The eZ430-Chronos wireless development kit is a powerful evaluation kit created by TI. This evaluation kit allowed us to program the watch very quickly with the provided debug and programming via USB dongle.
The door hardware was custom built around the CC1111EMK868-915 Evaluation Module Kit, which uses the CC1111F32 wireless System-on-a-Chip.

Power Consumption Estimates
The estimated duty cycle of watch is 10 unlock cycles per day. The estimated duty cycle of the door is 30 unlocks and 30 locks per day. Using the built-in 220mA coin cell battery, the watch that consumes 0.131mAh per day will function without a battery change for approximately 1,679 days or 4.6 years! Using the four 2500mAh, 1.2V batteries in series, the door that consumes 4.03mAh per day will function without a battery change for approximately 620 days or 1.70 years!

Security
In a sense, our wireless door lock solution is even more secure than the traditional method of unlocking doors using keys. To unlock the wireless door lock, the user not only has to have a previously paired watch, but also has to know the secret knock sequence to the particular door. Here, security is achieved by requiring a combination of something you have as well as something you know.

Something You Have – Texas Instrument eZ-430 Chronos Watch
On the watch, we store information about up to 21 paired doors in a simple database. The information includes a unique 16-bit door ID and a 128-bit shared AES key agreed with the door upon pairing. Each watch and door pair has its own designated shared key and unlock sequence. Using the shared key, the door and the watch can communicate securely.

Door ID		Shared 128-bit AES Key
0xFE12		01 6D 2D 83 66 64 0E 25 3B A0 41 0D 2D 83 66 FF
0x11D3		0E 25 3B A0 41 3B A0 410D 2D 83 66 FF66 64 0E

Table 1. Typical watch-side database (up to 21 entries stored in flash)

Watch ID	Shared 128-bit AES Key					Secret 96-bit Knock Sequence
0x434F		01 6D 2D 83 66 64 0E 25 3B A0 41 0D 2D 83 66 FF		50 FF 8C A0 35 32 80 EF 41 0D 00 00
0x100A		83 66 FF 66 64 0E A0 41 0D 2D 0E 25 3B A0 41 3B		35 32 80 2D 83 66 64 00 00 00 00 00
0x100A		A0 35 32 80 41 0D 2D 3B A0 41 0D 2D 0E 25 3B 03		99 FF 30 00 00 00 00 00 00 00 00 00

Table 2. Typical door-side database (up to 68 entries stored in flash)

Upon user’s request, the watch can initiate a key renewing process that would allow a new 64-bit partial key to be generated. This new partial key will be encrypted using the old key and sent to the door. Door will combine this new partial key with part of the old key. Doing this process twice will rotate a completely new 128-bit key between the watch and the door. We recommend the user renew their partial key every month.
To prevent repetition attack, we implemented a session token system. When initiating a door unlocking, key renewingor sequence changing process:

1. The watch will send an unencrypted SYN packet to discover nearby doors
2. The door will receive the SYN request and looks up the watch in its database and find the shared key
3. The door will generate a 32-bit pseudo random number known as the session token for the particular watch
4. The token is encrypted using the shared key and sent to the watch in a SEC packet
5. The watch then decrypts the SEC packet; verify its validity by looking for a pattern in the decrypted message; and save the token for the remaining of the session
6. From now on, during the session, the token will always be included in the encrypted part of the packet and both the door and the watch will verify each message using the token
7. Upon success completion of the operation (e.g. successfully unlocking the door, renewing partial key, or changing the knock sequence), the token will be discarded by both ends and become invalid

If the attacker tries to repeat the door unlock sequence by recording the radio transmission, the attempt will fail due to an invalid token. Neither can an attacker disrupt the session by requesting a session token on the watch’s behalf, because the session token will only change upon success operation or when it expires.

Something You Know – Secret Knock Sequence
If an attacker gets hold of your watch that contains the 128-bit shared key to your door, it is still not the end of the world. A 96-bit unlock knock sequence is required to unlock the door. This sequence can be set uniquely for each watch-door pair. This sequence is collected by measuring the shock on the watch using the integrated 3-axis accelerometer. The user can simply and quietly tap on the watch to input such sequence.The collected sequence is then encrypted using the shared key and sent to the door in the SEQ packet for verification. The door normalizes the sequence and verifies its validity against the data stored in its database. However, normalization allows the user to tap at a different speed each time as long as each tap has consistent relative length.

Suppose we have the following simple sequence: “TAP [… pause …] TAP TAP [… pause …] TAP[… pause …] TAP”. The watch will see shock at each tap. Our algorithm works as the following:

• Start the accelerometer and look for the first tap.
• Found first tap, start a timer to time the pause length between the first tap and the next tap.
• Found second tap, stop the timer, and store the pause length (8-bit, in 6 millisecond resolution) as the first element in an array (of size 12). Start timer again to time the pause length between second tap and the next tap.
• …
• If timer time out meaning the pause is too long, or the entire array if filled, we then call the sequence finished.

Now the array contains numbers that measures the length of the pauses between each tap. So for the sequence “TAP [… pause …] TAP TAP [… pause …] TAP[… pause …] TAP”, the array content will look like:

0x50	0x10	0x45	0x49	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00

To make sure we can match the same sequence knocked at different speed, we have to normalize the sequence by scaling the longest pause in the sequence to 0xFF like this:

0xFF	0x33	0xDB	0xEB	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00

Now the sequence is normalized and can be compared to a previously normalized sequence for validity. A probability of match is computed based on the normalized sequences. Of course, we cannot tap a sequence perfectly, so some margin of error is allowed.

As you can see, a sequence consists of 5 taps will result in4 pause lengths. We allow up to 12 pause lengths which can be translated into 13 taps totally. The more taps your secret knock sequence consists of, the more secure your door lock will be.

The secret knock sequence is also not permanent and can be changed securely over the air upon user’s request. The door has to be put into a special mode called the “sequence changing mode” to allow nearby watches to reset their secret sequence. This can be done by holding the button on the door for at least 5 seconds. After the user taps in a new sequence (twice for confirmation), it is encrypted using the shared key and sent to the door in the PWD packet. The door will then store the new sequence in its database and exits the “sequence changing mode” automatically. Again, we recommend our user to change their secret knock sequence in a regular basis.

Potential Vulnerability
No security system is perfect. We’ve hypothesized some security vulnerabilities in our system.

The biggest problem is always the initial pairing of watch and door. To pair a watch to a door, the user have to put the door into a special mode called “pairing mode”. This can be done by holding the button on the door for at least 10 seconds. In pairing mode, the door will accept RAW packets which are used to exchange initial keys. The user can initiate a pairing process from the watch. The watch will collect random bits using the accelerometer and construct a 128-bit shared AES key. This key is transmitted unencrypted in the RAW packet over the air to the door. The door will accept the key and store it in its database only if it is in pairing mode. The door then acknowledges the watch about the success completion of the pairing, and exits the dangerous pairing mode automatically. Pairing mode can also be used to reset the 128-bit keys once those keys get out of sync between the door and the watch. This out-of-sync state is a rare state which will happen when an acknowledgement packet is lost during a key renewing process. We try to minimize this risk by always sending multiple ACK packets.

As you can see, the door is considered “naked” when it is put into pairing mode. A potential solution to this problem is to decrease transmission power in pairing mode such that the watch has to be very close to the door. Another potential solution is to run a Diffie-Hellman key exchange process and requires the user to input a pre-shared secret in order to pair with the door. The secret can be in a form of tapping or button press sequence.

Source Code
The source code for the entire project can be found on our repository:
http://svn.ziyan.info/svn/doorlock/trunk/

Alternatively, you may view it using the nice SVN web interface.

And if you like it, please do vote for us on the competition page: http://www.designmsp430.com/ULPDesigns.aspx?sampleId=0cfa3c10-b810-42ff-9429-13acad020ae6

Update: Hardware Revision 2
Zack has just completed the PCB design for hardware revision 2. In this revision, we got rid of the reed switch to detect door close. We will have two IR sensors, one pointing out from the side of the box for detecting door close, the other pointing into the apartment for detecting approaching person and unlocking the door when the person gets close enough. A buzzer is also included to produce battery low voltage warning and other messages.

Recent news about Microsoft trusting StartSSL root CA in the security update has brought my attention to this company called StartCom. They offer instant SSL certificate signing for free. Turns out Microsoft Windows is not the only operating system that trusts StartSSL’s root CA, it works on Linux, Mac and iPhone as well. So, to secure your own website for free, here is how you do it:

First, go to www.startssl.com to register an account. They will send you an E-mail with a verification code. You will have to check your E-mail account to activate it. This will generate a personal certificate that is automatically installed into your browser. (By the way, the website is poorly designed such that Safari won’t work, use Firefox or something else instead.)

The next step would be to verify that you are the owner of the domain you intend to secure. In the StartSSL control panel which you will see once you login, click on the Validation Wizard and select validate domain and use one of the E-mail addresses to verify it. Again, you will have to check your E-mail and activate it using the code that you received.

Now use openssl to generate your private key:

openssl genrsa 4096 > private.key

4096 means the key is 4096 bits long. You have to use at least 2048 bits for StartSSL to sign it.

Then create a certificate signing request:

openssl req -new -key private.key > request.csr

Go back to StartSSL control panel and click on the Certificate Wizard. Choose Website SSL/TLS option. Skip the private key generation. Upload the entire content of your request.csr file. The wizard is quite easy to follow, just finish up and you will get your certificate in PEM format. Save it as a file on your local system.

Soon you will receive another E-mail saying you’ll need to read this page to complete your certificate installation. This is because your computer will trust the root CA but does not know about the intermediate CA that actually signed your certificate. You will have to tell your website visitors that you have a chained CA so that they know how to follow the chain of trust. To do that, you can follow the instruction on the page if your server is listed in there. However, it did not work for me since I am using plesk control panel provided by media temple. There are two tricky things I needed to deal with:

First is that plesk does not provide a field for intermediate CA when you upload the certificate. To deal with this, you need to concatenate your intermediate CA with the root CA and put the combined text into the CA field.

Second thing is more like a glitch. For me, ziyan.info was the full domain of my virtual server. This messes things up because plesk would automatically provide an invalid self-signed cert for this domain. It turns out the solution to this problem was quite simple. Just go to the Server preference setting in plesk and change the full domain to something else, like server.ziyan.info. And the invalid certificate will stop messing with my website.

On another note, now you’ve seen how easy it is to get a free SSL certificate, you should be aware that anybody can do it. So, next time you do online banking, please actually review the certificate of the bank website in detail before you login. Make sure the certificate authority is trustworthy.

I’ve looked at a few different methods to reliably and simultaneously localize and map environment for mobile robots. In particular, one can use Extended Kalman Filter (EKF) to deal with Gaussian error in robot motion and achieve fantastic results (at least according to the papers). However, EKF is evidently hard for me to implement at the moment and robots are generally difficult to model. So I’ve been playing with a simple approach to the localization problem which is called scan matching. Because we generally mount a 2D laser scanner on our mobile robots at a fixed location. These scanners usually produce very accurate distance measurements to obstacles. By calculating the relative angle and displacement for two different scans taken at different time, we can essentially correct the robot odometry. One of the easiest way to do that is through iterative closest point (ICP) algorithm.

ICP involves just a few steps: First, we pair each new points found on the scan with a closest point in the so far known environment. Then, we calculate an optimal transformation using mean square cost function. And we apply that tranformation to our scan. And finally iterate all these steps until we are satisfied.

I guess ICP is so greedy that it may get stuck at a local minima. But keep in mind that the laser scanner usually scans the environment 3-5 times a second. The chances are our robot has barely moved between those scans. And with the help of encoders, which are not accurate enough by themselves, we can give the algorithm a head start by providing a “guessed” transformation obtained from the encoders.

The most costly part of the algorithm is probably in the searching for nearest neighbour for each new scan point. However, with the help of K-dimensional Tree, the searching part can get O(n log n) when the scan points are randomly distributed.

I have a C++ implementation of the ICP algorithm that matches two PPM images and calculate the relative transformation between them:
http://svn.ziyan.info/svn/default/trunk/algorithms/icp/

Some time last month, RIT interns had a chance to meet with Steven Sinofsky, President of Microsoft Windows Division. Here is the picture from that private Q&A session. (Cookies and milk session)

Meanwhile, Windows component teams were having their own RTM parties back here in Redmond. Some two hundred people crowded in the break room right outside of my office to celeberate the achievements of the core networking team. And there was cake. (And booze.) For the 5,000 ish developers working on Windows, the next two days leading to the weekend have just become holidays!

My position is Software Development Engineer in the Core Networking Team of Core OS Division (COSD). Our team owns Windows Core Networking APIs and technologies such as Winsock, TCP/IP stack, WFP, IPsec, IPv6, WSK, WinINet, Http.sys, WinHttp, QoS, and System.Net. And my job for the summer is mainly investigating aspects of wininet.dll that we can improve. This can be achieved by trying out different ideas and tracking performance gains of those improvements. By focusing on performance of wininet.dll, essentially we are trying to speed up IE, and lots of other Microsoft and third-party components that utilizes wininet.dll as the HTTP client.

The first day at Microsoft was a long and somewhat boring new employee orientation. Finally at 4:30p that day I met with my mentor Rick James and manager/boss Ivan Pashov. They are really nice people and helped me with The second day, my computers are pretty much set up. My development machine is a quad core at 2.66GHz with 8GB of RAM. And at first I got an old test machine, but somehow it got toasted (I promise it wasn’t my fault). So I ended up in our admin, Suzanne’s office. Suzanne is really nice and she gave me a new machine. Now my new test machine has an AMD 64-bit dual core CPU at 2.90GHz with 2GB of RAM. I also have two LCD screens and a nice Microsoft keyboard that splits in the middle, forcing me to get used to hitting Y with my right hand (I never noticed that I should be using my right hand to hit Y). The third day my E-mail and phone start to work, and I started to appear in their database. Due to the massive scale of Microsoft, it took a long time to get my record replicated throughout the corp network. And the phone they have for me is a really cool one. It is an IP phone that connects using Ethernet. It has a touch screen and a fingerprint reader. It uses Office Communicator and sync all the contacts I have with the server. I think IP phone is a cool idea for offices because you will be able to keep your number when moving from office to office. However there is also the drawback that if your corp network somehow fails, which happens all the time in firms, your phone would not work either.

One of the best feeling working at Microsoft is that they trust me as an intern with the entire Windows 7 source code. I was able to check out the massive code base and play with it. Maybe it’s just me, but it feels like dreams come true when you touch and modify the source of Windows. For sure I will have a wonderful summer learning Windows in depth.

The benefits and perks working for Microsoft are just awesome. There are so many, so my list is kind of messy here. First of all, the monthly salary is much higher than that of the industry average for interns. Free soda, coffee, tea and other soft drinks are everywhere in office buildings. There is a huge “Microsoft Mall” inside of Microsoft campus itself. Pretty much everything around Seattle is potentially discounted for Microsoft employees, including lots of restaurants and cell phone service carriers. The corporate housing came fully furnished with bi-weekly house keeping, sort of like an extended stay hotel. The free bus pass provided works everywhere in Puget Sound area free of charge. The pro sporting club membership also comes free with employment. Also the shuttle connectors on Microsoft campus are mostly hybrid cars with wireless transceivers that tell the drivers who and where to pick up and drop off. Simply go to a receptionist and ask for a shuttle, the computer will tell exactly which car will come pick you up along with the ETA. And of course all the sneak peaks and Microsoft products are shared within the corporate network. So basically the idea is to provide interns with pretty much the same set of benefits and perks as permanent full-time employees.

Anyway, I am quite enjoying the summer here at Microsoft. Exciting things are happening every day. And my schedule is always packed.

This project is an attempt to implement a 3D visualization of simultaneous localization and mapping (SLAM) based on raw sensor data provided by the Player robotics framework.

This project is useful for both research and application purposes. Visualization of SLAM in research can help robotists better debug their robots. It can also provide much more information for remote robot operation where the robot can be controlled based not only on vision from the cameras, but also on 3D terrain mapped using robot sensors. Furthermore, by overlaying camera frames as texture onto the built 3D terrain, a precise model of the environment physically and visually can be built and saved.

Approach
The project uses player/stage as the robotics interface because player/stage offers a fantastic hardware abstraction layer for robotics programming for various robot hardware platforms. One can also easily build drivers for player so that their customized robots can be interfaced through player as well. SLAM Visualization for Player means the visualizer will work with any robot that provides the player interface with zero configuration.

The project is built using C++ on Qt4 which is a cross platform rich user interface library that provides a wrapper for OpenGL. Using Qt, the visualizer is able to utilize some of the powerful tools like threading, windowing and the signal/slot mechanism.

Technical Details
The structure of the program is fairly simple. It consists of the following components:

• Map: an object that contains occupancy grid map as well as a 3D texture map for image data overlay
• Robot: an object that uses player client to gather information from the player server, and plots the laser data and camera frame onto the map
• GLWidget: is a GUI that displays the robot and the map using OpenGL

When mapping laser data, probabilistic mapping technique is used. Basically, it updates each occupancy grid cell when new evidence about an obstacle or open space is gathered. So the probability of an obstacle increases or decreases as the robot continuously scan the area. The mapping of laser data also uses a probability model for each laser beam such that it simulates the sensor error in the laser range finder and try to minimize it using the probabilistic mapping technique.

When mapping camera frame, 3D texture were built to hold pixel level data. Some trigonometry calculation were performed to project the frame onto the 3D model. It works like a reverse ray tracer where the pixel color on the image in 2D determines the pixel color in corresponding 3D texture space.

The map has the ability to save into files and load from files. Such abilities give the visualizer the mean to playback recording or continue exploration based on previous recordings. Map is automatically saved when the visualizer window is closed. Though Ctrl+C on the command line will terminate the program with data loss.

Finally, the GLWidget provides complete control of the camera in the 3D scene. There are two modes for the GUI. When started up, the mode defaults to robot following where the camera will following the robot’s movement. Using double click, one can toggle the robot following mode. When it is off, one can move around the mapped environment freely. Holding the left mouse button and drag will move the x, y coordinate that the OpenGL camera is looking at. Holding the right mouse button and drag will adjust the yaw and pitch of the OpenGL camera. Scrolling using the mouse wheel will zoom in and out of the scene.

Results
The resulting visualizer program works amazingly. One can watch the 3D probabilistic map being built as the color of the portion indicate its certainty. As the robot travels on the map, red is 100% free space while blue shows 100% obstacle.

From an overhead view

From a robot view

From a bird’s eye view

If a camera is present, not only does the visualizer plots the physically map of the environment, it also overlay camera frame data onto the correct physically location, providing a complete 3D model of the environment.

3rd floor of building #9, the electrical engineering department

4th floor of the new extension of building #9, the senior design center and the robotics club

A closer look at the 4th floor of the building #9 new extension.

3rd floor of the new extension of building #9, the computer engineering department

The screenshots above were taken from playback recording. The recordings were made using a real robot called AMOS III. These recordings were provided at http://drop.io/ghszhux. More screenshots can be found at http://picasaweb.google.com/ziyan.info/ZiyanSBlog.

Future Enhancements
There are a number of things that I plan to work on when I have spare time:

• Multi-robot: supports multiple robot working on the same map. This is fairly easy on the mapping side. On the display side, I need to find a way for user to specify which robot the OpenGL camera should follow
• Multi-camera: supports multiple camera per robot. This is also in fact very easy. Instead of calling mapFrame once every cycle, just call it twice with different camera geometry and frame data.
• Sensor location configuration: provide a way to adjust the sensor location relative to the robot center. Right now, camera geometry is hard coded.
• Visualize Path Planning: using player’s planner interface, I should be able to also plot planned path for the robot on the GUI. Then again, this is tricky for multi-robot.
• Visualize other debugging information: the visualizer should be extended to include raw camera viewer, positioning data, system health data, etc. These could just be text displays.
• Image Distortion Problem: At the moment, we average over a number of frames to get mapping of textures. This methods blurs the walls because of motion blurs and asynchronized sensor data. I need to find a better way to deal with these problems.
• Improve reverse ray tracing: the way camera frames are being mapped onto the 3D texture does not work perfectly. Some improvement may be made around that area.

Source
This project is available as open source freeware under GPL. The source code is maintained at http://svn.ziyan.info/svn/default/trunk/slam

The goal of this project is to create a program that controls a Pioneer robot to navigate on a floor and reach a list of waypoints in their given order. The robot will start at one of given 8 locations and has to localize itself based on sensor data. The robot has no laser range finder and is only equipped with 8 sonars.

The solution that our team (me, Kevin Cheek and Zach Busser) come up with is to use probabilistic mapping to localize the robot, use A* to compute shortest path, and finally use artificial potential field to execute low level sub-goal navigation and obstacle avoidance.

Screenshots

Floorplan in C-space

Robot on its way to waypoint #1

Robot on its way to waypoint #2

Robot on its way to waypoint #4

Source Code
The source code for doing all this is available under GPL at:
http://svn.ziyan.info/svn/mrp/

Project Report
Our project report covers a lot of details:

Algorithm Design
Overview
The algorithm design can be broken down into four parts: the main Retriever loop, the localizer, the planner and obstacle avoidance.

When the program is started up, waypoints are read from the provided file. The floorplan is loaded into a GridMap. A C-space map is created from that floorplan. A local map with a higher resolution is created to map sonar readings.

The mapper runs on a separate thread and continuously updates the local map. The localizer also runs on a separate thread and continuously calculates the most likely starting position of the robot based on the local map generated by the mapper. The planner runs on a separate thread to plan and keep track of the robot’s progress along the path to the goal. The obstacle avoidance algorithm also runs on a separate thread to avoid obstacles and work towards a nearby sub-goal given by the planner.

Localization
The localization algorithm can be broken down to two parts:

• The local mapper thread (localization.Mapper), which takes sonar range reading and updates a local probabilistic map. The coordinate system of the local map is relative to the starting location of the robot. The odometry starts at (0, 0, 0).
• The localization thread (localization.Localizer), which constantly compares the generated local thread to the floorplan. This thread, tries to rotate and reposition the local map onto the floorplan using the position candidates. It figures out how much portion they match. The most likely starting position is determined at any given time by the ranking of those position candidates. Then, the robot’s real location is calculated by offsetting and rotating the odometry based on the starting location and orientation.
  Since the local map will be continuously updated by another thread, this thread continuously recompute all the scores for all the position candidates. It provides the path planner with the most likely position at any given time.

Path Planning
Our path planner used the brushfire algorithm to construct a Voronoi graph of the map. We could then use Dijkstra’s algorithm to search the map from start to end points. Unfortunately, our implementation had some problems: either the Voronoi graph was disconnected at points, or the graph generated was too “thick”, meaning that there were too many nodes in the graph. The first case caused Djikstra’s algorithm to fail to find a path, because a path did not exist on the disconnected graph. The second case returned a path; unfortunately, this path took an extremely long time to find and often used graph nodes that should have not been in the graph in the first place. For instance, nodes directly along a wall. Because of this, we were forced to fall back on an A* search over the grid map. We constructed the cost function for A* in such a way that it vastly preferred staying equidistant from walls, adding an overall Voronoi feel to the approach. The unsuccessful plan planning code for Voronoi and Djikstra is located in the src/pathPlanner folder; the relevant algorithms are located in src/pathPlanner/PathPlanner.java. The A* code over the grid map is located in the src/planning folder. The planner actually creates a list of every grid point along the path; only every 10th point is sent as a waypoint to the obstacle avoidance algorithm. In general, this allows the obstacle avoidance algorithm to do its work while still maintaining the overall shape of the planned path. The differences between the planned path and the path the robot actually travels are most pronounced during turning.

A planner thread was used to keep the robot on track. The planner is able to detect which segment of the path has been successfully navigated by the robot. It provides the obstacle avoidance algorithm with the next sub-goal along the path. If the planner detects that the robot has been kidnapped, or it has strayed too far from its path due to avoiding obstacles, it will replan so as to maintain an efficient path to the goal. This was most evident in simulation when we were able to literally kidnap the robot, without having to physically pick it up. We also needed to replan if the robot relocalized itself to a different robot and starting position; obviously, the old path would need to be changed if this happened. This was most evident in the two robots in the right hall, which are difficult to tell apart until the end of a hallway is reached.

Finally, when a robot reaches a goal point, it sleeps for five seconds to indicate that it has indeed reached the goal.

Obstacle Avoidance
We used artificial potential fields to do low level obstacle avoidance. The basics of the algorithm are fairly simple: the robot is attracted to the goal point, and repelled by obstacles. We used a K value of 1.0 and an inverse cube repulsion to model the potential fields; the inverse cube means that the robot will be extremely strongly repelled by objects that are very close to it, but less affected by objects that are further away. The threshold point for “close” was settled upon as half a meter away. We also added a linear term so that the robot would be affected somewhat by objects that were a bit further away; this term modifies the potential field for objects two meters away or closer. Sonar information is read in a separate thread and passed to the potential field; this interaction is controlled by a semaphore. The code for the potential fields is located in src/navigation/PotentialField.java.

Experiments
Simulation
The grand simulation experiment involved running robots p0 and p2 on projpoints1, and robots p1 and p4 on projpoints2, with staggered start times. At this point the machine used for testing became a bit sluggish, so we stopped with four simultaneous robots. All four robots successfully localized very quickly, on the order of a few seconds, and began planning the path to their goals. Robots p0 and p2 reached their first goal at times where they did not conflict, but as robot p2 started towards the second goal it had to avoid robot p0 moving towards the first goal. This was successfully accomplished. After robot p2 reached the second goal it stopped, finished with the goal points. This meant robot p0 had to maneuver around it to land within the half meter radius; this was also accomplished successfully. The second set of robots were more staggered because robot p4 starts further away from the initial goal and was started later. The upshot to this was that p1 and p4 met in the northeast hallway and had to avoid each other, which they successfully did. The final difficult part of the simulation was going in and out of the robot lab for the fourth waypoint in projpoints2. The robots were somewhat slow to navigate the doorway and the white robot was just beyond it, but in both cases they successfully made it into, and back out of, the robot lab.
The times for each robot are as follows:
p0, projpoints1: 9:19
p1, projpoints2: 12:53
p2, projpoints1: 5:42
p3, projpoints2: 14:24

Real World
Since we did not have every ready at the time of real world testing, we did a number of real world tests on various component of the project.

The artificial potential field was the first thing tested, and required the most modifications since it was the closest to the robot. In particular, we needed to add code to slowdown or stop when very close to objects to prevent smashing into them due to momentum in the real world. We also significantly revised our general potential field equations to come up with parameters that would be successful both in terms of avoiding objects, and squeezing through tight spaces like doorways and crowded hallways. The sub-goal navigation for APF (navigating through points on a path) was also tested in real world. The robot was able to successfully reach the sub-goal and avoid obstacles on the way.

The localization/mapping was also tested on the field. The algorithm worked for some starting points while others required a little bit help from the human operator. For example, the starting point inside the robot lab was very hard to localize because there are a lot of furniture in the room. But once the robot was herded outside of the room, it ran down the hallway and successfully localized. It definitely took a longer distance and more time to localize in all cases because the evidence collected was so noisy. On the other hand, the biggest problem with the real world localization was that the odometry of the robot was not accurate enough. For lewis, the robot tends to deviate to the left. Also, turning tend sto skew the odometry and make the map impossible to localize. A much more fine-grained localization is needed in the process (SLAM).

This is the final checkpoint for the raytracer project. The goal is simply to map produced images into real life luminance and compress them using different operations to produce film like effects.

Original picture:

Using Ward’s operator:

Lmax = 1

Lmax = 1000

Lmax = 10000

Using Reinhard’s operator

Lmax = 1

Lmax = 1000

Lmax = 10000

Final Code
The raytracer is currently open source under GPL, you can check it out here:
http://svn.ziyan.info/svn/default/trunk/raytracer/

The project is done in C++ with the help of boost library. It produces a PPM image as the result of the rendering.