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.