June 5, 2006

Today we began learning basic control theory. Using Simulink, we simulated a 3-D PID controller. We also went over the software used in the lab to control the autonomous helicopters. The software establishes a real-time loop--gathering location data, generating code, and controlling the helicopter's real-time position.

June 6, 2006

Today we continued our work with Simulink. We modified our PID controller, substituting a step input for the original constant vector input. We also improved our driving skills, taking the car outside for the first time.

June 7, 2006

We familiarized ourselves with the VZSoft and VZAnalyzer software. We went over the tracker system in more detail. We unpacked a set of tracker sensors, mounted them to a piece of styrofoam, and experimented with picking up the sensor signal in VZSoft and adjusting the coordinate system in VZAnalyzer.

June 8, 2006

We assembled the second RC Hornet, but it would not run properly on the first try. We had to take the gearbox apart and reassemble the parts.

June 9, 2006

We adjusted the steering system on the new car and made a successful test drive. Then, using Simulink, we simulated a circle trajectory. We spent some time driving the cars.

June 12, 2006

We attempted to complete the Simulink position controller but ran into some complications. We began work on the tracker sensor mounting, and drove the cars.

June 13, 2006

We made a trip to Home Depot hoping to find parts for our tracker sensor mounting, but were not able to find anything to suit our needs. In the afternoon, we tried to go to Hobby Lobby, but got lost due to bad directions from Google. We ruled out many options for the mounting system and got a better idea of what we really needed to be looking for.

June 14, 2006

We took a trip to Wal-Mart and found what we needed-wooden dowels to use as support pillars, wood screws to attach them to the car, and hooks to fit on the tops of the dowels to hold the plexiglass platform we plan to create. In the lab, we fit the dowels onto the cars, but experienced some problems. The manual screwdrivers we were working with did not allow us to properly drive the screws into the dowels.

June 15, 2006

In the morning, we purchased a sheet of Plexiglass from Home Depot. However, Home Depot no longer cuts Plexiglass and the machine shop in FGH was closed due to illness. We spent the afternoon researching and found ten papers on motion controllers that we believe may be helpful in our controller design.

June 16, 2006

Lewis allowed us to use his woodworking shop in the basement of FGH. With the help of a drill press and band saw, we were able to cut two Plexiglass platforms to mount on top of our cars.  By the end of the day, our sensor mounting platforms were complete.

June 19, 2006

Today Graham returned to campus and inspected our mounting system. He also looked at our circle trajectory and pointed out some errors. With a clearer picture of what he had in mind, we were able to complete the trajectory properly. Later, with Graham, we went over the papers we found last week. None of them really included the information we needed, so we did some more searching.

June 20, 2006

We spent all day today researching, both online and in the Science and Engineering library. We were looking for a paper or book that outlined a simple motion controller system for steering and throttle on a wheeled vehicle, or at least derived equations of motion for a wheeled vehicle system. We ran across a few papers that seemed somewhat helpful, but still could not find exactly what we needed.

June 21, 2006

This morning Graham introduced "Local Path Control for an Autonomous Vehicle" (Nelson and Cox). This 1988 paper outlines a controller used for automated carts such as those used in offices and factories. We spent the morning carefully reading the paper, then extracting from it the equations we thought would be useful for our own controller. In Simulink, we implemented caculations for tangential, normal, and heading errors. Graham and Peter spent some time rethinking the equations used in the paper, specifically the derivation of the angle used for the steering signal. The end result of today's work was a simple P-controller for our car's steering.

June 22, 2006

Today we derived and implemented a simple controller for the car's throttle [speed]. This controller determines the distance the car needs to travel from its current point (detected by the tracker) to the endpoint (determined by the trajectory we tell the car to follow). The larger the distance, the faster the car will travel. Towards the end of the day, we began work on writing a new trajectory. The car should start at (0,1,0) [meters] on the lab's coordinate system. After 30 seconds, it should travel to (0,-1,0), passing through the origin. At the end of this linear path, it should stop. We created a Simulink block for this trajectory, but were unable to test it due to some technical difficulties with both Simulink and RTLab.

June 23, 2006

After solving the problems from yesterday (Note: Simulink seems to have trouble with multiple mux-ing and de-muxing--data gets lost!), we were able to determine that the block we created yesterday did not fulfill the requirements of the trajectory. After spending some time with it, we got it to work-in simulation. Once the car was actually introduced to the trajectory, things did not go as planned. The problem is that if the car is not placed exactly at (0,1,0), the controller tries to move it there. However, the steering and motor system on the car is not precise enough for such manuevers. We'll have to spend more time on this problem.

Today also introduced new complications. For example, when the car needs to be at a z-rotation of -180 degrees, but it is a few degrees off, say at -182 degrees, our heading error calculation interprets this as +178 degrees instead. Instead of moving 2 degrees counterclockwise, the car rotates 358 degrees clockwise to get itself into alignment.

June 26, 2006

Today we began by running the system in real-time and looking at the tracker data to determine exactly how the coordinate system of the lab is set up. We discovered that the z-rotation is measured along the y-axis. On the positive x side of the y-axis, the z-rotation goes from 0 to -180 degrees. On the negative x side of the y-axis, the z-rotation runs from 0 to +180 degrees. Upon determining this, we changed our straight-line trajectory so that the car would need to travel along the x-axis instead of the y-axis. In this manner, we avoided any situation in which the car's heading might change rapidly from say +179 to -180. We were able to run a successful test of our straight-line trajectory.

We created a Word document outlining basic procedures of using the lab system. We also wrote an outline for our Midterm Powerpoint presentation and progress report.

June 27, 2006

We began by taking pictures and video of the car to use in our presentation. Graham explained finite state machines to us, and we improved the speed controller using a Stateflow block in Simulink. We also began planning a way to resolve the z-rotation issue, also by using a finite state machine. It will, however, take some time to perfect and implement our initial plans.

We began work on our presentation for Friday.

June 28, 2006

We continued working on the FSM for the steering controller. This FSM will re-normalize the z-rotation data coming in from the tracker so that it ranges from -90 to +90 instead of -180 to +180 degrees. In this way, a turn of more than 180 degrees will be prevented.

We continued working on our presentation and our paper.

June 29, 2006

We went over our presentation with Graham in the morning and then made some changes. We had some difficulty with transitioning our paper into LaTex. In the afternoon, we practiced our presentation with the entire group.

June 30, 2006

We gave our presentation this morning at ISIS.

July 5, 2006

We made some attempts to re-create our results from last week. However, we could not get the car to follow its straight-line trajectory properly. We spent most of the day adjusting the speed controller, trying to find the right balance of speed states for the car. In the afternoon, the coordinate system of the room shifted by 90 degrees for no apparent reason.

July 6, 2006

Since the coordinate system of the room was still off, we noted the change and adjusted our trajectory to compensate for the difference. We experimented with changing the error calculations for the steering controller. We noticed that when normal error approaches zero, the position error indicates that the car should turn, even when it should not. We are searching for solutions to this problem. We believe our controller equations may need re-thinking.

July 7, 2006

After much experimenting, we determined that the position error equation was not effective for our controller. We modified the controller so that "alpha"-the angle the car should turn-is now calculated using a combination of heading error and normal error. With this adjustment, the car behaved just as we wanted it for straight-line trajectories. In the afternoon, we worked on adjusting the circle trajectory we wrote earlier so that it fits our existing infrastructure.

July 10, 2006

We wrote a diagonal-line trajectory and tested it. With some fine-tuning of our speed controller, we had very good results. However, when we tried to implement the circle trajectory, we ran into some problems. The controller cannot seem to compensate correctly for errors in x and y position and z-rotation with the circular path. We experimented with a finite-state machine to normalize the car's steering signal, but we could not get it to function correctly. Anyway, we were not sure that it would be applicable to trajectories besides the circle.

July 11, 2006

We experienced many technical difficulties today. In the morning, we worked on adjusting the circle trajectory's equation for calculating z-rotation. By the afternoon, we finally had an optimal trajectory. However, when we tried to test it, we found that something had gone wrong with the laboratory equipment, halting experimentation for the remainder of the day.

July 12, 2006

Today we figured out what had gone wrong yesterday-it was not a problem with the equipment, but rather with our trajectory. We were able to solve the problem by adjusting our trajectory's z-rotation equation. Once that problem was solved, we spent the rest of the day experimenting with changing the constants in our P-controller, attempting to make the car follow the circle trajectory.

July 13, 2006

N

A

S

A

July 14, 2006

The car continued to refuse to go in a circle. However, by the end of the day, we noticed a rather obvious problem with the finite state machine used to renormalize the measured z-rotation. We left for the weekend hoping that solving this problem would enable the car to follow the circle trajectory.

July 17, 2006

The car still refused to go in a circle. We found another problem with the z-rotation FSM. We made a necessary adjustment, but it still did not solve our problem. Continual adjustments to the P-controller constants were not helping either. We made the decision to upgrade to a PD-controller. It seems to be giving us much better results so far. We are experimenting with the straight diagonal-line trajectory to optimize the constants (Kp for the proportional gain and Kd for the derivative gain), and hope that the circle will be successful now.

July 18, 2006

After finding optimal constants for the straight-line trajectory, we moved back to the circle. Unfortunately, the optimal Kp and Kd for the straight line did not work well with the circle trajectory. After changing these constants several times without being able to observe a noticeable change (and without seeing a single completed circle), we went back to the drawing board.

Going over our error equations, we determined that the position error (Ep=pi/2-arctan[Etangential/Enormal]) was causing some problems. We modified the equation (to the simpler Ep=arctan[En/Et]) and finally saw our car complete a circle or two without veering off and crashing into the wall or going under a table. Obviously, however, these circles did not follow the trajectory perfectly. There was significant overshoot. We spent the rest of the day tuning our constants (C1, C2, Kp, and Kd) to see if we could get a more accurate circle.

July 19, 2006

Today we contined attempting to tune the controller constants, but did not get results as consistent as yesterday's. It became difficult to discern whether or not a certain change in constants was actually helping or harming the car's behavior. We went through our Simulink controller blocks again and found another small mistake in the z-rotation adjustment FSM. Fixing that problem helped somewhat with experimental consistency, and by the end of the day we had reasonably good results with the constants C1=.7, C2=.3, Kp=.25, and Kd=1. The circle repeated six times before  the car lost track of the trajectory and veered off.

July 20, 2006

In the morning we started with the same constants as yesterday afternoon and achieved a reasonably similar results. We began the process of tuning the constants again, but soon noticed that the results were completely inconsistent. Changing the constants seemed to make no difference in behavior. Then we found a mistake in our speed FSM. After correcting this error, we started tuning the constants again, with mixed results. Sometimes the car will follow the trajectory quite closely, but then significant overshoot will occur on the next iteration. We found it very difficult to determine how accurately we actually need the car to follow the trajectory. Part of the problem is that the tracker and the sensors mounted on the car are not completely reliable. Sometimes it looks like the car is passing through a "dead spot" in the room, but that  spot is not always there. Sometimes one of the sensors will fail, so the tracker is not sending complete information to the controller. We had to be careful to stay aware of the tracker information, because when the tracker/sensor system fails, it is not indicative of a problem in our controller, and it is best to just restart the iteration. In the end, we decided to be satisfied for now with the constants C1=.69, C2=.31, Kp=.35, and Kd=1.5.

In the afternoon, we wrote a new trajectory incorporating both straight-line and circular movement. The car should travel in a straight line in the positive y-direction, complete a semi-circle, and travel in a straight line in the negative y-direction.

July 21,2006

Frustrated with our inconsistent results, we consulted Automotive Control Systems (Kiencke & Nielsen). From this text, we borrowed a different equation for position error calculation. This equation is simply the arctangent of (Yr-Ym)/(Xr-Xm). It is less complicated than our former calculation, and seems to be giving us more consistent results. We managed to tune the constants for the circle trajectory, ending with C1=.7, C2=.3, Kp=1, and Kd=1.5.

In the afternoon, we lost our network connection (one of the servers crashed) and we were unable to access our Matlab license. Therefore, we closed for the weekend.

July 24, 2006

This morning, it took some time to get the server repaired. When the system went back online, we tried running the numbers from Friday again. Predictably, the results did not match up. Eventually, however, the car managed to complete five reasonably well-formed circles, and we decided we were satisfied. We spent the rest of the day testing our other trajectories (the straight line and the combination), making small adjustments to fine-tune the system.

July 25, 2006

By adjusting the FSM for the speed controller, we were able to get very consistent results for the circle trajectory. We moved on to a more complicated "racetrack" trajectory. The circle travels a straight line along the y-axis, completes a semicircle, travels back along the y-axis in the opposite direction, and returns to its starting point via another semicircle. The car followed this trajectory reasonably well until its battery gave out. With a fresh battery, the car moved faster, so we had to adjust the trajectory's timing to compensate.

July 26, 2006

With the racetrack looking great, we decided to write a figure-8 trajectory. It took some time to perfect the trajectory (in simulation). Unfortunately, when we tried to actually test it in real-time, we discovered a major problem with our controller. Because, when designing it, we had counterclockwise circular motion in mind, the entire controller is biased towards left-turn, counterclockwise motion. The car could not effectively execute the clockwise semicircle needed for the figure-8.

July 27, 2006

Trying to adjust for the controller's counterclockwise bias, we discovered inconsistencies in the steering finite state machine. We spent most of the day re-analyzing our equations, attempting to account for every possible state (every possible difference between the measured and reference z-rotations). In the afternoon, Professor John Koo stopped by the check on our progress. When we told him about the problem we'd been having, he gave us an equation to quite simply re-normalize the z-rotation differences from -pi to pi. This equation effectively solves the problems we've been dealing with since our midterm presentation. Now we have one day to try to use this new tool.

July 28, 2006

Now that our controller uses a different equation to calculate the heading error, we had to tune the constants again. Finally, we managed to have reasonably consistent clockwise and counterclockwise circles, as well as diagonal lines. We moved back to the figure 8 trajectory. The car was still having trouble following it, so we experimented with changing the speeds of the two semicircles to see if the car could actually handle them.

In the afternoon, we were able to mount a battery pack onto the car for the tracking system. The car can now travel completely autonomously!