• Looked at processors

Team Meeting

• Looked over processor choices
• Worked out how we think the overall system should work: Each team will create a website that will be able to control both vehicles. Created a block diagram of the "big picture" of how the vehicle control system will work.
• Also Created a block diagram of what peripherals the processor will hove to control.

• Attended Weekly Meeting of Friday

Week Summary:
Total Time Spent: ~2.5 hours

• 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

Week Summary:
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)

Week Summary:
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.

Week Summary:
Total Time Spent: ~ 5 hours

• 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.

Week Summary:
Total Time Spent: ~ 3.5 hours

• 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.

Meeting Friday (1 hour)

• Design Review to take place next week (Friday 11/11/11)
• Teleconference with Hong Kong next week...
  • Main Goal is to talk about a protocol for controlling the vehicles. Along with that we need to discuss vehicle platforms and how that will affect the protocol.
  • Talk about getting a connection made between our micro and theirs and get them to do something in the real world.
• Task: Get our micro connected to the internet and have it control something based on commands received from the net.

Week Summary:
Total Time Spent: ~ 9.5 hours

Meeting with Team (Tuesday) (3 hours)

• We created a powerpoint presentation for the design review on Friday.
  • I personally made the section on component selection.
  • We will meet again on Thursday after teleconference to finalize and review what we are going to say.

Teleconference with HKUST (Thursday) (1 hour)

• participated in a teleconference with Hong Kong.
• they have decided on a tank platform as well.
• We will each come up with protocol ideas and brainstorm on them over rhea. Right now it looks like well be using 16 bit instructions.
• plan to have a teleconference next week at the same time (thursday 8:00am)

• Met with team right after teleconference to finish up our PowerPoint slides for the design review. (2 hours)

Friday

• Met with team before the design review to practice presenting.(1 hour)
• Gave design review in EE206. Got some feedback:
  • Calculate battery consumption and decide how many batteries/what type to use
  • Pandaboard might be very difficult to interface with.

Week Summary:
Total Time Spent: ~ 6 hours

Team Meeting (Tuesday)(3 hours):

• We split up into groups to get a couple things done. Jason worked on getting Ubuntu to run on the pandaboard while Kin Chin, Chris, and I worked on improving HKUST's proposed protocol.
  • At first we were going to just go with our original plan to have 16 bit instructions where the first byte would be an opcode such as "go forward" or "turn turret left" and the second byte would be a quantifier that would modify the command (i.e. how fast to go forward). We realized however that this does not leave very much room for fine tuned movement control because you can only send one movement control command at a time. For example, you can't go left and forward at the same time which might be desirable if you wanted to do more of a soft left turn in a tank such as ours. HKUST's protocol deals with this problem nicely by sending all movement control data in one byte. So we decided to preserve that part in our protocol proposal.
  • Here is what we came up with for our second byte:
    
  • The one thing that we wanted to change about HKUST's protocol was that their first byte did not leave room for peripherals that might require more than simply an on/off command. We wanted to make it modular so that many different types of peripherals could be used.
• Jason got Ubuntu working on the pandaboard but we could not get the camera to work. It didn't seem to mount at all when it was plugged in. We did however get the wi-fi to work on the pandaboard and were able to connect to the internet.

Weekly Meeting Friday (1 hour)

• Work out possibility of putting a checksum in protocol. Also include a start and stop byte. Including these things would mean that some combinations of bits could not be used for actual data. This is a problem with our current design because any combination of bits is meaningful with the current configuration. This will need to be reworked slightly in order to include these things.
• It came up in conversation that we should put the webserver on the pandaboard since it already runs linux. This would greatly simplify things and also provide credit for making the website to the senior design team. We realized that if this were the case it would be dumb to have a wireless module connect a couple of inches to the server when we could just send the control micro serial data commands instead. We came up with tasks based on this new model.
• <task>: work on serial communication from pandaboard

Week Summary:
Total Time Spent: ~ 4 hours

Team meeting (tues) (x hours)

• Jason's webpage was getting a bunch of errors, so we spent a while trying to figure out why. It turns out that permission had to be given to access the files stored in the webcam folder. A simple chmod fixed that.
• We then verified that the panda board was outputting correct RS232 data by hooking it up to another computer and using putty to display characters. <took a video of this but file type is not supported in Rhea>
• We then worked on initializing the serial port on the Kiel micro. After much fidgeting with it, we finally got it to transmit and receive characters from putty terminal on another computer. However, we were not able to get it to receive characters from the pandaboard. We first realized that it was the male->male RS232 cable that we had that caused the problems. It didn't mirror the pins like we thought it would (i.e tx on the pandaboard was connected to tx on the micro). To fix this we soldered our own cable that correctly connected the right pins together. This didn't work either. we decieded to meet later on in the week to resolve the issues.