9-30-09

With school starting back up, I now have time once again to work with APRIL. I have begun a research internship (for college credit, likely 3) with UROP under Professor Olson and will continue where my summer fellowship left off. As of now I am continuing to work on the half-duplex serial communications (for use with the ax-12+ servo). Although in theory everything should be working great, I have run into one serious issue. Transmission to the servo is working fine, it accepts commands, but unfortunately the receiving of signals from the servo is failing. The issue is intermittent, which in my experience is due to either a mechanical problem or a hell of hard to find issue in the electronics. In this case, I think it may be a noise issue. I set the non-active pin (either Rx or Tx) to be high impedance and while that reduced the failure rate, there is still a considerable failure rate in receiving bytes. As of now it is only successful in retrieving 2/5ths of the data sent to it. The bytes received randomly varies between being off by 0-2 byte offsets. I'm almost confident it's a noise issue. The oscilloscope has given me some clues and I'll look into it more probably Friday.

7-31-09

The new Orcboards are in! Professor Olson created a revision that is signficantly smaller than the current Orcboards. What this means is that they will be both cheaper to produce and take up less space on space crucial platforms like the Splinters(planned to be mass produced) and the autonomous aircraft. While Professor Olson did the majority of testing for the new revision, I was asked to help in testing to see if everything was fine. I tested all the peripherals and most of the I/O(input/output), along with the current capabilities of the new Orcboard. Everything looks good!

I've been also asked to add support for half-duplex serial communications. Normal serial communications involves both a transmit and receive wire, each one sending or receiving data as a sequence of electrical pulses. This is called a full-duplex setup. A half-duplex setup involves sharing one wire between both data sent and received. This involves making the output high impedance when data is being received (to prevent shorting). Since there exists no firmware for the second serial port, all that will be added also. Thankfully firmware already exists for the first serial port and this can be used for the second with slight modification.

What I learned.

Throughout this summer my perspective on research and my future in general has been changed by my fellowship. At the beginning of my fellowship I was very concerned about my ability to contribute to my research group. Furthermore, I was worried that what I would be working with would be something I may not find interesting. These concerns however passed very quickly as I started my fellowship. As I worked on the various projects related to my research group APRIL, I began to build a strong confidence in myself and my work.

My first project was developing firmware for an electronics board so that it could support a type of electronic communication. My previous experience never came close to dealing with what I was presented with. Furthermore, my professor was very insistent on having me rely on myself to learn everything on my own. It was a surprise that my professor had more confidence in my abilities than I had. He was right though, and through a lot of work and research I was able to carry out my tasks and my contributions allowed other team members to advance their own projects with my work. It's an amazing feeling seeing others use and appreciate what you have contributed to the group.

If there's one thing I don't like about my work it is debugging. Debugging is required in order to test and fix any issues you have after you program the device. A car mechanic who rebuilds an engine has to test and find any issues that may exist at the end. The same goes for anyone who works with electronics. After programming you have to find all the bugs that exist, and sometimes those bugs are so obscure that it takes brute force methods to fix it. With my first project I had to use an oscilloscope and manually read the signals, diagnose what they meant, and find the issue. In the end the problem was an obscure and undocumented issue where doing one command before another led to an issue with the configuration.

This fellowship has really built both my confidence in my abilities and my ability to work with others while still retaining an independence that keeps me from needlessly relying on others. Most of what I do I do on my own, and I have learned only to ask questions when I can't find the answers on my own. This has built my skills in research and problem solving. I know now that when I have a problem, I go thoroughly through the documentation and learn as much about the problem as possible. This however doesn't mean that I can't rely on the experience of others. With my first project I did eventually ask my professor a question concerning it, and he gave a small hint that in the end made a big difference.

I feel that I have accomplished a lot during my fellowship. The skills I have learned are the same skills that exist on many job postings for my career. It is a good feeling to know that many of the problems I will face as an engineer will be things I already have direct applicable experience with. I do not feel that my learning experience will end with my fellowship, and I am now committed to staying with my research group long after my fellowship is over.

7-15-09

The past few weeks I setup both the Wii MotionPlus and the Wii Nunchuk for use with the orc board. The Wii Nunchuck will allow for both joystick control along with some accelerometer readings, while the Wii MotionPlus is an incredibly cheap gyroscope that can be used on the robot. The Wii MotionPlus works by providing a value indicating it's motion along 3 axis. This value is roughly divided by 20 to provide how many degrees of movement. Normal Gyroscopes can range anywhere from $40 to much more, so a cheap $20 gyroscope will help to make the production of robots much cheaper. The LM3S9B92 microcontroller has been delayed due to the issues with OpenOCD, and the CAN firmware is still being worked on. I expect to get the ordered OBD-II connector in soon (this connector allows for connecting to vehicles that support CAN, virtually every car produced during/after 2003 supports it). I also will be getting several 1K Ohm resistors to fix the issue of the beacon not support straight 9V, an unfortunate design flaw that needs to be fixed. For those interested in interfacing with the nunchuck and motionplus, I will make another post soon with detailed instructions.

Impressions of my research fellowship

My first impressions of working for APRIL are a bit surprising to myself. I expected a very difficult time both fitting in and being able to do the work provided by my professor. However, thankfully I have found my niche in the research group and have been successful in developing and contributing to the group. My project involves working with embedded devices, so a strong background in embedded electronics is needed. My previous experience with electronics, especially digital electronics, enables me to successfully complete many of the tasks assigned to me. For example, when interfacing with the wii nunchuck, I needed experience with both communication protocols and creating a more user friendly interface around that communication protocol. My experience with protocols like UART for the 8bit devices I previously worked with allowed me an easier time working with I2C. Furthermore, knowledge of electronics hardware is important, as you need to modify boards, build boards, and repair them. My previous summer job last year was essential to helping me with these issues. My previous job involved building circuit boards, which is perfect for what I'm doing now. I feel that I contribute a unique skill set to my group and believe that my previous experiences are the only reason I can contribute successfully to my group. I am very excited at how much I have learned, especially since it is something I likely will be working on throughout my life in my career as a Computer Engineer.

6-9-09

The past week has been spent learning the various software packages provided by Prof. Olson. These include Vis, a java package for outputting graphics, and the uorc java controls. The example program allows one to control the motor controllers on the uorc with a joystick. For those who forgot, the uorc is the board I have been working on since I got here. I have also been looking into the CAN protocol. Hope to implement that sometime this month (although how I will test it is still an unsure thing).

6-2-09

Last Thursday was spent debugging (trying to fix) the I2C interface for the uorc. Unfortunately an issue prevented me from receiving a proper response from the sensor. I spent the entire day working on this. I used the oscilloscope to view the transmission as a digital signal. I was able to directly view the transmit and receive and see what the issue may be. The sensor would always respond with random values, which appeared as a series of 8 random voltage states of either 0V or 5V.


Sunday I met with Akash as he showed me the LED beacons and what they were supposed to do. The LED beacons that he provided information for is intended to output a pulse on the LED which give a camera the beacon's ID number. This ID number allows the camera to locate and track each robot, along with providing other robots with an idea of which robot it is looking at. I took the string of 1s and 0s that make up the pulse and output it at a frequency of 10Hz. Chris, another member of April, is currently working on implenting support for these beacons on a PC.


Yesterday, Monday, I finally discovered the issue that was preventing I2C from working. In a microcontroller everything is defined by register values. Registers simply hold a binary number and define the behavior of a microcontroller. In this case, I was giving a value to one register before another in the wrong order, which caused the first register to reset. This caused the frequency of the I2C interface to rise substantially higher, which meant the sensor I was communicating with did not have enough time to respond. By simply switching the order in which I was modifying the registers, everything started to work perfectly. I also began to work on the LED beacons. I programmed one of the beacons with a small program I made and gave it to him to work on. Unfortunately the other LED beacons were not accepting any programming requests from the programmer.


Today the first thing I did was finish up the I2C interface and started to work on the LED beacons. After talking with Akash, the person who designed/made the boards, I discovered that the voltage I was programming at was too high. I set the voltage just slightly high enough to overcome the voltage drop of the resistor and LED which caused the programmer to think a short was occuring. By lowering the voltage from 5.1V to 3.7V, the beacons began working perfectly. I spent the rest of the day building 7 beacons. Thankfully my technician background and work experience last summer afforded me an easy time soldering the SMD components.

5-27-09

On Monday I started working under Prof. Olson (of APRIL) for my Jack Kent Cooke fellowship. On Monday at 11:30AM I met up with Prof. Olson as he introduced me to the board I'd be working on. The board is called the uorc, and has its own webpage at www.orcboard.org. He showed me a quick demo of the uorc in action, including both programming it and interfacing with it using the ethernet cord. After finishing the demo, he let me work in the lab.


In the lab, I first soldered on a header (a socket for the programming cable). Afterwards, I covered the bottom of both the programming board and the orc board with an insulating tape to protect it from shorting and damaging it. I grabbed one of the available laptops and installed the necessary development files including the source code and toolchain (the programs that make the source code able to be programmed into the orc board). I programmed the orc board and repeated the demo that Prof. Olson showed me earlier.


The rest of the day was spent pouring over the entire source code of the orc board, which consisted of the operating system. I modified the operating system to include a new task that would send a string through the ethernet to the laptop. Typically you do slight modifications to source code to better understand what is going on. Having never worked on either operating system driven embedded electronics or 32 bit processors, this was a completely new experience for me. Thankfully my work with 8 bit microcontrollers were very applicable to many of the basics of 32bit embedded development. By the end of the day I felt that I had a pretty good understanding of what I was working with.

Yesterday, Tuesday, I spent the entire day implementing the I2C peripheral. I2C is a fairly simple peripheral, which works by having the master, in this case the orc board, send an address over the bus (the data lines) and subsequently either request a transmission or receive information. Having worked with the UART peripheral I felt fairly comfortable with this project. I used the skeleton source file provided by Prof. Olson and used the SSI peripheral source code as the basis for what to include in the I2C source. Since I am still unfamiliar with the details of working with an operating system, I really depended on the ISS source code as a reference on how to prepare the operating system for the peripheral. The major issues include interrupt handling and protecting the process from any undesirable interrupts that may occur which would cause a loss of information.


I ended Tuesday with a good basis for the peripheral, but unfortunately while compiling the actual peripheral showed no signs of working on the oscilloscope (instrument used to read voltage and frequency). It was only this morning that I realized that a simple mistake in the source was to blame. I accidently had the write variable length equal to the read variable length, and since the read variable length was set to 0 it automatically bypassed sending any data over the I2C periphearl.


Today, Wednesday, I spent fixing up the code, analyzing the output with the oscilloscope, and finishing the transmit and receive processes. As of now a rough version seems complete but I won't be able to tell until tomorrow if it actually works when Prof. Olson brings in a I2C device to test it with. I recently took pictures of my workspace and a friend and fellow APRIL member who is also working with the firmware that has been helping me recently.

UROP Research

This blog has been created to act as a journal for my experiences as a Jack Kent Cooke Fellow. I expect to do research under Prof. Olson and look forward to recording what I am doing over the summer. I became a Jack Kent Cooke Fellow because of my interests in electronics and computers, and look forward to learning an incredible amount over this summer.

My research involves working with the Orc Board that was developed by Prof. Olson. The Orc Board is essentially the controller and interface between the computers that send and receive information and the sensors and motors that are connected to the robot. My work involves implementing peripheral protocols (such as I2C and USB) and also helping with future Orc board projects, including upgrading to newer microcontrollers. I also help with building and programming the LED beacons that are used to help identify the robots.

All of this will enhance my abilities with working with embedded electronics, specifically the 32 bit ARM processors and also embedded operating systems. These are key skills used in my profession and will be invaluable for my future.