I got in my ALES shop the other day and am now starring on construction. Yes I know I still have to post a build log for the other glider. But today I got the springs for the pull-push system and the horizontal stabilizer mount installed.
Saturday, January 7, 2012
Monday, July 18, 2011
Tuesday, July 12, 2011
Homework and DARPA
So one of the homework questions that I had for my 'knowledge based systems' course got was about the major AI contests which kind of got me thinking a bit about why not smaller challenges. While there are some things that will only ever be answered by the large and expensive grand challenges, there is another aspect that is lost with them. It is important to note that participation in these projects like the DARPA grand challenge or DARPA urban challenge is a very exclusive thing and requires large interdisciplinary teams. While much good can come of this, I think there is also some harm in all the focus being placed on these projects.
First, a large portion of academia in unable to participate in these challenges. While my college has a graduate CS program, we lack ME and ECE programs, which would obviously be required for these projects. Additionally we are not a tier 1 university, but instead focused on professional development. However that does not mean that non of the students have anything to offer to hard problems, and by alienating so many smaller colleges and universities we loose a large portion of potential minds that could work on some of these problems.
Another problem that I see is that many of these research groups, because of the huge financial input into the problem, are likely to take risks on outrageous ideas. Sometimes these are critical for making breakthroughs, or even just seeing that another legitimate solution exists.
So why not mini challenges? What I see is that the Maker/DIY/Hacker community has incredibly sophisticated tools, everything from arduino, beagleboard, Digilent FPGA boards, Android devices, and the Kinect. As an R/C enthusiast I also know that we have quite sophisticated platforms. So it does not seem like there is a technical reason not to fund small teams of 2-5 individuals, probably university students, with a standard platform to perform some given tasks in a scaled down challenge.
In addition to the additional mind share working on the problem I think some other huge things will come out of something like this. First, we will see more people with sophisticated AI backgrounds graduating from ALL colleges and universities instead of just the elite ones. This is great for companies that might want a low cost/risk way to explore some of these ways of solving programming problems.
Additionally I think we will see one huge impact if standardized and smaller scaled hardware is used, that of massively filtered data. One of the great things that the human mind does is filter at various levels. Why can we not use the same ideas in AI to take real world problems and simplify them, but still come out with satisfactory results?
First, a large portion of academia in unable to participate in these challenges. While my college has a graduate CS program, we lack ME and ECE programs, which would obviously be required for these projects. Additionally we are not a tier 1 university, but instead focused on professional development. However that does not mean that non of the students have anything to offer to hard problems, and by alienating so many smaller colleges and universities we loose a large portion of potential minds that could work on some of these problems.
Another problem that I see is that many of these research groups, because of the huge financial input into the problem, are likely to take risks on outrageous ideas. Sometimes these are critical for making breakthroughs, or even just seeing that another legitimate solution exists.
So why not mini challenges? What I see is that the Maker/DIY/Hacker community has incredibly sophisticated tools, everything from arduino, beagleboard, Digilent FPGA boards, Android devices, and the Kinect. As an R/C enthusiast I also know that we have quite sophisticated platforms. So it does not seem like there is a technical reason not to fund small teams of 2-5 individuals, probably university students, with a standard platform to perform some given tasks in a scaled down challenge.
In addition to the additional mind share working on the problem I think some other huge things will come out of something like this. First, we will see more people with sophisticated AI backgrounds graduating from ALL colleges and universities instead of just the elite ones. This is great for companies that might want a low cost/risk way to explore some of these ways of solving programming problems.
Additionally I think we will see one huge impact if standardized and smaller scaled hardware is used, that of massively filtered data. One of the great things that the human mind does is filter at various levels. Why can we not use the same ideas in AI to take real world problems and simplify them, but still come out with satisfactory results?
Sunday, July 3, 2011
ADK adventure
Last night I tried working with the USB host shield on the arduino and ran into a number of problems. It seems that the version of the USB Host Shield library that is distributed with the ADK package does not work right on linux. This is kind of annoying. I then spent some time mucking around with version two of the USB host library, since the author notes that the first version is no longer being developed. It appears though that this is a major rewrite of the library, and in no way compatible with the androidAccessory library. I did manage to get the authors quality control test program functioning after correcting a case sensitivity issue.
I am now playing around with this again (yes, I am that thick headed) using the most recent copy of the first version of the library available on github. I also ran across this blog post which may be a tad helpful.
http://marioboehmer.blogspot.com/2011/05/android-adk-with-standard-arduino-uno.html
Lets see how this all works....
And it works. I thought I tried that last night, but sometimes things just work so much better after a nights sleep and starting over. Using the version from github works while the one from google does not. I connected it to the full version of the demokit android app, I will now add in some hardware and see what happens.
I am now playing around with this again (yes, I am that thick headed) using the most recent copy of the first version of the library available on github. I also ran across this blog post which may be a tad helpful.
http://marioboehmer.blogspot.com/2011/05/android-adk-with-standard-arduino-uno.html
Lets see how this all works....
And it works. I thought I tried that last night, but sometimes things just work so much better after a nights sleep and starting over. Using the version from github works while the one from google does not. I connected it to the full version of the demokit android app, I will now add in some hardware and see what happens.
Tuesday, June 28, 2011
Saturday, June 25, 2011
cool things to play with sometime
http://wiki.processing.org/w/Android
and obviously
http://openkinect.org/wiki/Main_Page
and obviously
http://openkinect.org/wiki/Main_Page
Wednesday, June 8, 2011
Pair IT
So I had read an interesting article (http://pragprog.com/magazines/2011-06/pair-programming-in-a-flash) over the weekend about pair programming. I have done a bit of pair work with Ron, but not terribly much. It seems like a potentially great idea, especially if you can mix junior and senior level guys together, there is a great deal of learning that can happen, and it is a great way to mentor.
The interesting thing however that I thought of today is that most of my pair work is not while coding but with deploying servers. Over the last few months I have been more involved in helping set up webapp servers in conjunction with our IT department. The observation I had is that we are essentially doing paired IT, in much the same way that the pragmatic guys are saying to do paired programming. My observation is that paired IT for deploying webapps is a very good way to do things. Things move very quickly using this technique, and there is very little down time working with new services that have to be deployed. I think one of the keys here is also the combination of people involved. IT is obviously IT, with little programming experience, but a wealth of background in managing servers and networks. Then I am a programmer with a decent background in server technology. That combination I think leads to an effective pairing, where the task can be approached by two people with differing views. The other advantage I notice is that when things go wrong it is in many cases a much shorter troubleshooting period, since having a developer right there means that looking at stack traces is more fruitful in many cases than it is with only IT personnel looking at it, or having to send it to a developer. Obviously this still happens since I am often not the developer for the project being deployed, however I think having that combination of skills is a great way to pair in IT.
So, here are some guidelines I think might be useful:
- Deploy new services/webapps in a pair
- One member of the pair should be from IT and the other from webops or development
- experiment with ideas singly, not in pairs
So, I think this is just as good of an idea as pair programming, and can really make deployments fairly painless and quick.
The interesting thing however that I thought of today is that most of my pair work is not while coding but with deploying servers. Over the last few months I have been more involved in helping set up webapp servers in conjunction with our IT department. The observation I had is that we are essentially doing paired IT, in much the same way that the pragmatic guys are saying to do paired programming. My observation is that paired IT for deploying webapps is a very good way to do things. Things move very quickly using this technique, and there is very little down time working with new services that have to be deployed. I think one of the keys here is also the combination of people involved. IT is obviously IT, with little programming experience, but a wealth of background in managing servers and networks. Then I am a programmer with a decent background in server technology. That combination I think leads to an effective pairing, where the task can be approached by two people with differing views. The other advantage I notice is that when things go wrong it is in many cases a much shorter troubleshooting period, since having a developer right there means that looking at stack traces is more fruitful in many cases than it is with only IT personnel looking at it, or having to send it to a developer. Obviously this still happens since I am often not the developer for the project being deployed, however I think having that combination of skills is a great way to pair in IT.
So, here are some guidelines I think might be useful:
- Deploy new services/webapps in a pair
- One member of the pair should be from IT and the other from webops or development
- experiment with ideas singly, not in pairs
So, I think this is just as good of an idea as pair programming, and can really make deployments fairly painless and quick.
Subscribe to:
Posts (Atom)