September 21, 2011 (1.5 hours):
Participated in teleconference with HKUST. The discussion included possible processor options as well as the general scope of the project. Also received the new usernames for the HKUST students created for the Rhea page - emailed them to the team members.

September 22, 2011 (20 minutes):
Updated the Rhea page with information about the teleconference for those who were not there.

September 23, 2011 (1 hour):
Attended weekly meeting with VIP group.

Accomplishments: Obtained usernames for HKUST members
Weekly Work Total: 2.7 hours
Project Work Total: 2.7 hours

September 27, 2011 (45 minutes):
Researched processors and wireless modules, updated brainstorming session on the Rhea page. Still a little unsure of what I think.

September 27, 2011 (30 minutes):
Created a whenisgood address to organize a group meeting to create a diagram of the desired system before our group meeting on Friday. Set meeting time after results from team members came in.

September 28, 2011 (1 hour):
Met with group members to create system diagram and discuss processor choice.

September 29, 2011 (45 minutes):
Finalized system diagram and did more research on a processor/development board.

September 30, 2011 (1.5 hour):
Attended weekly VIP group meeting. Updated block diagrams to reflect discussions at the meeting and updated the Rhea page with notes from the meeting.

Accomplishments: Completed preliminary block diagram layout of system. Decided on potential processor family.
Weekly Work Total: 4.5
Project Work Total: 7.2

October 6, 2011 (2 hours):
Attended group meeting to design initial draft of poster for VIP poster session. Finished initial draft of poster at home and posted a pdf version to the Rhea site to be reviewed at Friday's meeting. Link here : Poster

October 7, 2011 (1 hour):
Revised poster based on Dr. Johnson's initial impressions and researched wireless transceivers.

October 7, 2011 (1.5 hours):
Attended weekly group meeting and updated Rhea page with meeting minutes.

Accomplishments: Finished poster for VIP poster session
Weekly Work Total: 4.5 hours
Project Work Total: 11.7 hours

October 11, 2011 (30 minutes):
Reformatted and submitted poster to be printed.

October 13, 2011 (1 hour):
Did research on development boards presented on Friday's meeting.

October 14, 2011 (1.5 hours):
Attended weekly meeting. Picked up development board!

Accomplishments: Decided on a development board to begin prototyping.
Weekly Work Total: 3 hours
Project Work Total: 14.7 hours

October 17, 2011 (30 minutes):
Updated Rhea page with Oct. 14 meeting minutes

October 17, 2011 (1 hour):
Got "Blinky" to run using KEIL software!

Blinky

October 18, 2011 (3 hours):
Attended scheduled meeting to decide on project parameters.
Vehicle Platform: Airsoft RC Electric Panzer Giant BattleTank

• This vehicle was chosen because of its size and peripherals. It has plenty of room with a size of 2.5ft x 1ft.
• It also has a moving turret already which is perfect for mounting a camera. In addition, the tank fires air soft pellets! This control can be investigated and added to the specs for the control of our vehicle if we want it to be able to fire.
• We were concerned with the speed of the R/C cars of equivalent size - a lot of them up to 60mph. In addition, their cost was ~$150 and we are anticipating having to buy 2 to compensate for tearing one apart. At such a high speed, sensors to increase the autonomy of the vehicle would be virtually useless.

Wireless Module: RN-XV module

• This module was simply chosen because of price and because it communicates through UART which is available for the Cortex-M3

IP Camera:TRENDnet TV-IP110WN Wireless N Internet Camera

• It was very hard to find an appropriate IP camera. We wanted to find a camera that didn't depend on software. This camera is on the lower end of prices (hundreds were looked at) and it should work great.
• All IP cameras have to be assigned a static IP address. This will need to be an option on the controlling website. Even if the camera was integrated, an IP update on the vehicle would still have to occur.
  

IR sensors and pushbuttons were chosen based on price. There is no need for long rang IR sensors.

October 19, 2011 (2 hours):
I did more research on IP cameras as I felt very unsure of using one. Not only did I feel like using one would be lame, there were just too many problems to deal with. One major problem is that IP cameras require that you connect to them via Ethernet and set up a static IP address for them. This would be extremely inconvenient for our purposes as every change in location would require a manual change in the camera's IP address. Also, most IP cameras require that you use the manufacturers software to access them - usually with a login and password on a browser. With time I'm sure our group could hack this requirement, but that is not really something we would like to do. (Not to mention IP cameras run ~$90 for the cheaper models)

I found a $10 CMOS camera on SparkFun, and one of the comments stated that someone had success interfacing to it with a Cortex M3! This will cause a change in our wireless transceiver as the one we chose previously would not be able to handle the throughput needed. We will be able to use the same line of transceivers, we will just have to pay more. There are many other CMOS cameras that we can choose from and this will give us greater flexibility in terms of implementation. It will be much harder to deal with the video feed ourselves, but will surely be more rewarding in the end.

Also attended VIP poster session which went really well.

October 20, 2011 (1 hour):
Found a new wireless transceiver that can potentially handle the data rate for the video feed and has i2c and well as other interfaces. More details on this later as I dig into the datasheet. Also created groups that we will break up into for project development and updated all of my research on this page: Research

Accomplishments:
Weekly Work Total: 8.5 hours
Project Work Total: 23.2 hours

October 25, 2011 (3.2 hours):
Met with group to complete tasks discussed at Friday's meeting. Last week we decided against using an IP camera because of the limitations. This week we looked into the requirements of implementing our own camera module. Unfortunately, the math did not come out in our favor. IP cameras use MJPEG compression internally before outputting the video to the web - which natively streams the MJPEG format. If we did not implement our own compression:

(640 x 480 pixels) X (2 bytes per pixel) = 614,400 bytes per frame
(614,400 bytes per frame) X (20 frames per second) = 12.3 MB/s output = 98.3 Mbps output

All of the CMOS cameras output in a RGB format or similar - raw image data. For most cameras, this is 16 bits per pixel. Without doing our own compression, this image data would be impossible to send wirelessly. There is a library for C to convert RGB data to JPEG format, which then possibly be converted to MJPEG on the controller side. This could possibly be used on-board, but the speed would have to be tested.

October 28, 2011 (1.5 hours):
Attended weekly VIP meeting. Updated Rhea page with meeting minutes and created a Doodle poll for Video Conference #2 with HKUST.

Accomplishments:
Weekly Work Total: 4.7 hours
Project Work Total: 27.9 hours

November 1, 2011 (4.5 hours):
Group disassembled one tank and found out exactly how the controls work. The controller (left/right and up/down) are simply switches. There are 4 relays on the basic circuit board - two for each drive motor. One switches on to drive each motor forward, and one for backward, supplying the battery's voltage and current. The turret is controlled by a small motor connected to a large gear. We will definitely change this as it is hard to control.

I located enough information to drive a very slow PWM channel that switched one pin on and off. We then constructed a circuit to drive the motor. To be on the safe side, we decided to optically isolate the drive to the motor. We calculated the correct resistor values for the BJT we were using and did not get it to work. So we tried it without and still couldn't get it to drive the motor even though all calculations and measurements from the DMM pointed to it working. We called it a night. Pictures and calculations will follow once we retry on Thursday.

November 3, 2011 (7 hours):
Looked at an example PWM program for the micro and looked up information in the datasheet. PWM mode can be chosen for each channel in each of the four timers. This is selected by setting the TIMx_CCMRx register correctly.In PWM mode (1 or 2), TIMx_CNT and TIMx_CCRx are always compared to determine whether TIMx_CCRx≤ TIMx_CNT or TIMx_CNT≤ TIMx_CCRx (depending on the direction of the counter). The duty cycle can be adjusted with the TIMx_CCRx registers. I tried to combine the PWM initialization code with ADC initialization code and LCD code to control the CCR register with the ADC value, but have not gotten it to work yet. Thus the code used manually controlled the the PWM at a specific frequency and duty cycle.

I tried our circuit again for PWM motor speed control, and after an hour or two when the rest of the group came we figured out that the 2N3704 NPN BJT we were using was being fried by the collector to emitter voltage/current. We found this out when we noticed one became burning hot and did not operate correctly. Scott and I went to radio shack and got two TIP 120s (Darlington BJT). We rebuilt the circuit but the motor was still not responding to the PWM input. After probing the circuit we found the the 5V output from the microcontroller was not functioning correctly. We used the Agilent E3631A DC PSU to supply 5V to the rail and the motor finally responded to the PWM output.

Circuit Diagram

November 3, 2011 (1.5 hours):
Attended weekly VIP meeting and updated Rhea page

Accomplishments: Received tanks
Weekly Work Total: 13 hours
Project Work Total: 40.9 hours

November 8, 2011 (3 hours):
Worked on design review with group.

November 9, 2011 (3 hours):
Continued working on the design review. Acquired the Pandaboard and hooked it up - hit a roadblock as seen in the picture below. I will either need to figure out the password or load a different linux distro onto an SD card so I can actually proceed.

Ubuntu Login Screen

November 10, 2011 (2 hours):
Attended video conference with group from Hong Kong. We decided to meet next week with the agreement that we would each come up with our own version of an appropriate protocol for vehicle control and then compare them and decide on one for both groups next meeting.

Also finalized the design review slides and submitted them.

November 11, 2011 (2 hours):
Practiced and attended design review.

Accomplishments: Completed design review
Weekly Work Total: 10 hours
Project Work Total: 50.9 hours

November 15, 2011 (3 hours):
Met with group to work on our protocol and other projects. Scott, Kin Chin, and Chris worked to develop a protocol that incorporated some of the ideas that the HK group had proposed on the discussions page.

Meanwhile, I worked on flashing Ubuntu onto an SD card and adding the necessary files to allow it to boot on the Pandaboard. It worked on the first shot! Well, it booted on the first shot. I still had to add about 238MB of other files for the board which, among other things, added the wireless and bluetooth drivers.

I plugged in the webcam obtained from Dr. Swabey and tried running Cheese to see if we could see the video from the camera. It crashed the OS and rebooted. I kept the camera plugged in and tried again but did not get anything. The webcam choice on that app is stuck on /dev/video3 so I will need to do more research to find where the webcam is actually being mounted.

I got back with the rest of the group and we finalized our protocol proposal. Basically, it goes along with the HK teams desire for a 16 bit protocol. The first byte is used for the actual vehicle control. As you can see from the picture, drawn by Scott, there is a bit to signal a right turn, a bit to signal a left turn, and two bits to designate the turn speed. The other four bits will be used for vehicle speed. There are 16 distinct points for vehicle speed that can be utilized, split between forward and reverse. The interpretation of that number (whether signed or unsigned) will be discussed at the video conference.

The second byte will be used for peripheral control. One of the main problems we saw with HK's protocol plan was that the peripheral control didn't make much sense. We decided that the second byte will be split up into two 4 bit values, one designating the peripheral/action and the other being the control value (can be 0 or 1 or a value with higher resolution). We wanted to be able to expand our peripheral control capabilities without having to change the protocol while still keeping the data to 2 bytes.

November , 2011 ():

November , 2011 ():

November , 2011 ():

Accomplishments:
Weekly Work Total:
Project Work Total: