• briefly looked at vehicle platforms. We decided that we probably wanted to build our own vehicle platform so I looked for robotics kits that looked like they might make that task easy. Didn't find anything particularly interesting. Most robotics kits I looked at were expensive. It was also difficult to find something with just wheels and a body that would fit out needs...
• Poster for VIP poster session was completed
• Weekly meeting on Friday

  Total Time Spent:  ~1.5 hours

• looked at possible options for mounting a camera on board the car without interfacing it with the microcontroller. Found this as one possible option: http://foscam.us/foscam-fi8918w-wireless-ip-camera-11.html. (30 mins)
• Attended weekly VIP meeting on Friday. Chose a development board to start prototyping with: Kiel MCBSTM32EXL (1 hour)

  Total Time Spent: ~ 1.5 hours

• TASK: Install Kiel ARM-MDK software onto a VIP computer to start experimenting with the chosen development board (Kiel MCBSTM32EXL )

• looked at camera options. In particular this one: http://www.axis.com/products/cam_m1011w/index.htm and this one: http://foscam.us/foscam-fi8918w-wireless-ip-camera-11.html axis looks like it will be easier to interface with website. Also briefly looked at wireless transceivers suggested by Jason. decided RN-XV WiFly Module http://www.sparkfun.com/products/10822 might be a good choice to start with. Posted findings on the discussion page on Rhea (30 minutes)

Team Meeting (tuesday)(2.5-3 hours):

• found potential parts to start prototyping with including a vehicle platform, wi-fi module, wireless camera to mount on vehicle, and proximity sensors/switches. see here for details on choices
• Wrote a simple example program and loaded it onto the target development board that printed out names onto the LCD screen.
• TASK: determine if the development board has A/D and D/A PWM ports because it is not obvious if those features are padded out on our development board. We had a very hard time finding documentation on how to use the general purpose IO as potential analog input/output. Needs to be done because we might have to find a new dev board if these features are not available.
• After looking into wireless ip cameras, we decided that it would probably be to difficult to interface into the design. First of all the ip address of the camera would need to be manually set every time we needed to use it and then the website would need to reflect these changes. This seemed impractical. We thought that interfacing a CMOS camera with the board would give us greater flexibility in this area and ultimately be more effective.

• Set up a lab bench in EE 63 (wednesday) with a username and password. We will install the IDE for the micro on that machine. (10 minutes)

• Attended VIP poster session in MSEE (1.5 hours)

Attended weekly VIP meeting. (1 hour)

• Tasks:
  • Find out if the bandwidth capabilities of the wireless module will be enough to stream video.
  • Research camera options that are either neatly packaged or are able to be hand soldered easily. There was concern that the current choice of camera would not be able to be soldered to anything by hand because the contacts were very small.
  • Install windows onto the team laptop that I was given during the meeting.
• Talked about the idea of the vehicle possibly becoming an off-road exploring vehicle that would integrate things like gps, temperature, and orientation of the vehicle into the design. This means that these kinds of sensors should be taken into account when looking at other things such as the capability of the wireless transceiver to send all of this data in a timely fashion.

• INDIVIDUAL TASK: get windows loaded onto the laptop given to team.

Team Meeting Tuesday (3hours)

• (meeting summary: LRVC_oct25 )
• Wrote a list of all peripherals and their interfaces (PWM/SPI/etc...) that would be needed to interface to the processor. Available here: Media:Processor_interfaces.doc. Still not sure about the current development board in meeting all of these requirements.
• looked at camera options for a long time. We found that integrating our own camera would require A LOT of bandwidth.
• Looked up the bandwidth of the wireless transceiver (see above meeting summary) and decided that it depends on what we decide to do with the camera. All of the CMOS cameras output to much data to be sent over wireless. Our conclusion was that we would either have to figure out a way to interface an existing ip camera to a website or find a way to limit the amount of data coming from a camera.

• Emailed Chuck Barnett about putting windows on the laptop I was given. He said that he had XP for HP computers and that it can be weird to do on DELL that we have. He said to talk to ECN about getting windows on it.

Friday

• Dropped the laptop at ECN to have windows XP put on it. They said that it should be ready by Monday (Oct. 31). I also had them put Microsoft office on it just in case.

• Monday: Picked up laptop loaded with windows from ECN and put it in team EE63 locker.

Tuesday:

• Team Meeting (4.5 hours)
  • Disassembled tank to see how we might interface with it:
    - very easy to interface with. TONS of extra room to mount electronics inside.
    - tank uses relays to ramp up voltage to the motors and also to switch them on. We will probably throw out the on-board electronics and make our own. It will be easier and also way more effective than interfacing with what is provided. We will be able to send the motors variable speeds instead of the simple all-or-nothing interface that is currently there.
    - Motors are kind of small... we were worried about whether or not the vehicle will be able to move effectively with all of that added weight. Probably end up replacing the motors with bigger ones and keeping the original gearbox.
    - turret turns using the same kind of motor as the treads.
  • started a detailed outline of what information we want to include in our design review. Kin chin will try to finish and improve upon it.
  • spent a LOT of time trying to interface the micro-controller to a motor using PWM. We verified that the PWM was working and we used the following circuit:
    
    I did the calculations for what the R's should be by figuring out how much base current would be needed to drive 1 amp of current through the motor { Hfe * (base current) = 1A } but we could not get the circuit working. Tried the calculation several times but still didn't work. Since there is no information on the motor it's hard to tell if maybe 1 Amp isn't enough, we did some calculation wrong, or if there was a problem with the way we hooked up our circuit.
  • We decided to meet again on Thursday to try to finalize our design review outline and also to try and get this motor driver circuit working.

Meeting Nov. 3rd (4 hours)

• Met to tried and finish the motor driver circuit and the outline of topics to be included in our design review.
• Tried to get the motor driver circuit working using BJT's (2N3904) again but could not get them to work. We then figured out that the BJT's were getting extremely hot. We figured that we were running was too much current through the BJT using the circuit above.
• We then tried using a MOSFET (IRL...) but could not get that to work for possibly the same reason. We weren't really sure.
• We then decided to use the parts from the ECE362 motor driver lab to be sure that they could handle the amount of power we put through them. Went to radio shack to get the parts (Darlington NPN transistor and optical isolator). Got back and hooked up the circuit and it finally worked.
• Experimented with the PWM on the micro. obtained oscilloscope plots of the output and we were able to change the duty cycle and frequency but we couldn't really find a combination that worked really well to change the speed of the motor.
• Started putting the motor circuit on a PCB.
• Finished the list of things that we would like to include in our design review.