Due to complications and struggles with advisors and switching projects mid way our team was unable to really get any work done in the month of september.  This project went from being a UAV to a UGV and we will be entering the IVGC competition in 2010.

September 28

We finally got in touch with the person who worked on this project last year and were able to pick up and retrieve their vehicle.  Our first goal now is to get this vehicle up and running by the end of the semester.  The next few days will be going through all the components and things we have now and see where we stand.  Hopefully we will be lead on a good track and get a good start to this project. 

October 01, 02, 2009

Today I spent more reviewing previous years code and seeing how it was implemented.  There was a lot more classes and code then I have previously expected there to be.  Basically there are the LRF class that is used with the serial comm class to establish a connection with the LRF.  The same goes with the GPS.  The list goes on and on, but I feel like if I take it bit by bit ill be able to go through everything and start making some progress. 

October 07, 2009

I got the SICK LMS 291-S05 hooked up and running today.  Using the software that comes with the laser range finder I was able to get a graph that showed where the obstacles.  By moving objects around I was able to learn the positioning of the sensor in relation to objects.

My concern now is the baud rate.  The baud rate is 9600, which is the slowest for the sensor.  This low rate makes it look like the computer is not getting continuous input.  There is a delay from when I move an object in front of the laser range finder to when I see a change in the graph on the computer.  This will most likely be a problem when the vehicle is travelling because it wont be able to react in time.

My goals next time are to look into changing that and start implementing some software to gather data and be able to manipulate it so the vehicle can maneuver around obstacles.

October 11, 2009

Progress was made today in dealing with the Laser Range Finder.  I was able to figure out how to change the LRF default settings to comply with what I want.  This included changing the measurement settings to millimeter, how to make it enter continuous mode and get out of the mode, and changing the baud rate, etc.  In the future, I want to implement using the RS-422 connection instead of the RS-232 because the RS-422 allows for a faster baud rate of 500k which will allow for real time results.  Im still a little uncertain about how to code the serial connection between the software and the LRF, but I was able to find a good tutorial about how to do this and will be figuring it out soon enough. 

Hopefully by the next time I work with this ill have been able to create a test program to gather in the LRF data, parse it, and display it in a graph to check if the code is working properly. 

October 12

Today I spent time reading over some articles about serial communications to extend my knowledge when working with the LRF finder.  After talking to a student who worked on this project last year with the same hardware I found out that getting the LRF to work properly proved to be very problematic.  Instances where the program would suddenly crash and at other times work makes me think that getting a new one maybe in the future. 

After reading demo code on the LRF, I found out through the notes that the manual that comes with how to set it up is inaccurate.  The response that the LRF gives when you send a message to it to change a default setting does not come back like it shows in the manual.  This is unfortunate and I foresee many problems to come in the future with this.   Tonight I wrote up a driver program to just create an LRF object and to gather some data.  In the next few days I will be implementing this and see what results I get.

More unfortunate news though is that I fear to god that the computer I am supplied with is going to break at some point during this year.  Today the computer couldnt recognize that the AC adapter was plugged in and continued to run on battery.  This gave me about 40 minutes to work with before I had to call it quits.  I want to take my laptop from home and use it, but its going to be difficult to get the drivers for the hardware seeing that somehow the software is missing from previous years so I guess ill have to back up my source code just in case my laptop catches fire.

October 20, 21, 22

After working on the GPS unit these past few days there has been some progress.  I have implemented opening up the serial port connection and creating a thread to handle reading from the serial port, but I was unsuccessful in getting data from the GPS.  There were errors that came up about linkers so I am going to have to dive into that in the next couple days.  Hopefully Ill be able to get continuous data from the gps receiver so I can parse through it and gather all the information. 

Also I noticed that the cord that connects with the digital camera is missing and therefore we are going to have to order a new one

November 1

Today proved to be difficult in that the laptop would not recognize that it was being connected with AC power so I had about 35 minutes of battery life before being forced to stop working.  This is not the first time that this has happened and it is really frustrating because I want to get the serial communication class working because getting input from the components is a huge step into completing this project and it will drive all the other classes. 

November 5^th

The laptop still does not recognize ac power so once the battery is drained I will not be able to work with it.  I tried bringing my AC charger from home that is of the same computer and it still didnt work.  But when I plug the ac adapter in my laptop at home it says that the ac power source cant be determined.  So it might just be the charger. 

I am currently searching for drivers for the components as we do not have the software that came with it, which is a real bummer.  Im going to start compiling code on my laptop and make up test files with the sentences from the components to make sure that it will parse through it and do the calculations that I want.  Until I get the drivers for the components, there is a limited amount of things I can do.

November 7^th

I had talked to a representative from SICK, his name was Don Alexander.  He proved to be a big help about figuring out the driver situation with Windows and the LRF.  He first informed me that there are no drivers for the SICK.  He also informed me that the software used for the LRF is not Vista compatible but I could run it in compatibility mode in XP.  I did that, but it still couldnt detect the LRF.  I realized that I needed an usb serial driver, so I downloaded one from the internet (thanks Prolific!)  and I was able to get the software working with the LRF.  Now it was time to get the input data in VC++.  After getting all the code to compile when I first ran the program it caused my computer to crash because I forgot to close the LMS software.  Apparently only one process can access the COM port at a time.  If more than one tries to access it it causes the system to crash. 

At the end of the day I was able to open up the COM5 port where the LRF was plugged into and get some data.  The next goal now is to be able to get continuous data because for some reason the code while(killThreads == false) doesnt work when killThreads is indeed equal to false.  But I made it a for loop just for the purpose of getting data from the LRF and it worked. 

My next goals are to find out if drivers are needed for the other components, since the GPS unit uses a Serial to USB adapter, it should be no problem getting that to input data.  Basler has agreed to donate the cord for the camera to us for free for free publicity (logo on our car) which is good because it saves us money.