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.
Friday, July 31, 2009
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.
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.
Wednesday, July 15, 2009
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.
Thursday, July 9, 2009
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.
Subscribe to:
Posts (Atom)
