Revision as of 06:11, 2 November 2011 by Stack (Talk | contribs)

Scott Stack - Design Notebook

Week of October 3rd:

  • 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




Week of October 10th:

  • 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




Week of October 17th:

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

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 of October 24th:

  • 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 Barette 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 of October 31:

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

Tuesday:

  • Team Meeting (4-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 motow using PWM. We used the following circuit:








Back to Design Notebooks

Alumni Liaison

Have a piece of advice for Purdue students? Share it through Rhea!

Alumni Liaison