Fermentable Code

My Arduino board has arrived. That and my $100 worth of electronic components to start with. Unfortunately, I have already realized some stuff I forgot to order. Oh well, I can still play around with the board!

So, I thought that I was all prepared with the software to just plug the board in and go, but this was not the case. Apparently, there are some major issues with versions of the AVR gcc compiler on openSUSE. Here's what I did that finally worked:

• Added the AVR Cross tools repository (download.opensuse.org/repositories/CrossToolchain:/avr/openSUSE_11.2/)
• Installed avrdude (5.10-154.1), avr-libc (1.6.8-9.1), cross-avr-binutils (2.19.1-31.4), and cross-avr-gcc (4.3.3-23.1)
  Note here that only gcc 4.3 will work for this board (I'm not sure where I read that, but it was my experience too). I even tried compiling 4.3 myself, but that didn't work with a slightly different version of binutils. The above worked for me, though.
• Downloaded and unziped the software from the arduino site (http://arduino.cc/en/Main/Software). I downloaded the 64 bit libs.
• In the arduino directory I made softlinks to all of the avr-* executables in /opt/cross
• Some places talked about compiling RXTX for java, but I didn't have to do that. However, I do get a version mismatch on that library when I run the software; it doesn't seem to cause a problem so I ignore it.

I've been having an issue connecting the Arduino board to my computer, however. Many times I'll connect it and get this error in dmesg:
[ 501.160010] usb 3-1: new full speed USB device using uhci_hcd and address 4
[ 501.273010] usb 3-1: device descriptor read/64, error -71
[ 501.488013] usb 3-1: device descriptor read/64, error -71
[ 501.690014] usb 3-1: new full speed USB device using uhci_hcd and address 5
[ 501.803010] usb 3-1: device descriptor read/64, error -71
[ 502.017012] usb 3-1: device descriptor read/64, error -71
[ 502.220010] usb 3-1: new full speed USB device using uhci_hcd and address 6
[ 502.628010] usb 3-1: device not accepting address 6, error -71
[ 502.730010] usb 3-1: new full speed USB device using uhci_hcd and address 7
[ 503.138009] usb 3-1: device not accepting address 7, error -71
[ 503.138026] hub 3-0:1.0: unable to enumerate USB device on port 1

I've found that if I just try a few times unplugging and replugging that it will finally recognize it, but I'm not sure what the problem is. I tried running this command, but I'm not sure if it does anything at all. (Run as root)
echo -1 >/sys/module/usbcore/parameters/autosuspend


Hopefully that can help someone, now it's on to understanding electronics as a CS guy...

I released OriginDB 1.05 today. This is just a bugfix release. There was an issue with modifying the percent by mol / percent yield of reactants and products.

I also completely changed the interface to PubChem. Now instead of displaying in a web browser a search box is displayed and I do the searching in the background. This fixes our crash on Vista / Windows 7 and there were also some major javascript issues too.
However, I am still scraping the PubChem pages instead of using their "Power User Gateway (PUG)." I spent a while looking in to it, but it seems just way too complicated. I guess this is something else we should be striving for, an easy to use interface.

Download available here!

It's been almost two years in the making, but OriginDB is finally nearing a 1.0 release. I really want to get something out the door, so I'm going to make this a stable preview release. What this means is that there are still some features that aren't implemented, but something needs to be released.

This last semester I've had lots of help from my senior design time (Brian and Travis) here at Tech. The plan was to release at the end of the semester, but stuff happened and we still had some major features not implemented. I've been able to finish those up the past couple of days and I'm pretty sure I can call what we have now stable.

The major features that are missing are:

• Compound Editor cleaning
  There is a button in the compound editor that is meant to "clean" the current compound (i.e. put it in a pretty geometric form), but this does not work at all. It turned out to be way harder than expected, and I'll blog about that later
• Searching for user created pathways in the database
  One feature we wanted was a way to search / browse user created pathways that have been saved to the database. Right now you can save pathways to the database, but there's no way to find them again. Hopefully this will be implemented in the next few weeks, however.
• Optimized server
  We had also planned to optimize the server so that we could reduce the number of requests. This would also allow a progress bar to be implemented. This is probably the most ambitious future goal and might never be implemented.

And we also have a couple of bugs that won't be fixed before the 1.0 release, but I feel like it's better to get something out there for people to use.

• On Vista and Windows 7, if you open PubChem the whole program crashes.
  This is probably the most important bug to fix. I'll be looking into it a little before the release, but I doubt I'll find the problem.
• And there is a database error that randomly appears
  I have absolutely no idea why this is happening. If you repeat the request it works fine, but it just fails... randomly. This one is very frustrating.

Finally, all I have left to do is create an installer. We have a wonderful getting started guide, thanks to Brian and Travis, and we have a partially complete user's manual. In the coming weeks the user's manual should be finished up, but for now, the getting started guide should be plenty.

Hopefully in the next day or so it will be out. Keep an eye on the download page!

For my birthday, I asked for a Rovio. It is a pretty cool little platform and I saw it on woot for only $100. What a deal, I said.

Anyway, my plan is to create a little python script to control it, and then on top of that add some computer vision stuff to write some autonomous code. I think I'll be working this up to a cat play-thing. We are planning on getting a cat next year and this way it'll have something to play with. It seems like a pretty formidable task, but we'll see what I can do on it.

So far, just playing around with it from the web interface it's been working pretty well. Battery life leaves something to be desired, but it seems as though the battery is becoming conditioned and it's getting better. Also, when you tell it move it doesn't always move exactly where you expect it to. (In fact I've heard this from other sources that use this platform too.) But hopefully the computer vision stuff can take care of that issue.

The API for the Rovio is all CGI commands found here. It's a pretty nasty specification without many details, but I think I'll be able to work it out.

I guess now is a good time to now that there has been some work already done on a python API for the Rovio at University of Buffalo by Jonathan Bona and Michael Prentice. (Link) The code can be found on github here. The reason I'm not using any of that code is 1) it really only is the API layer and it won't take me too long to write that myself / it will help me learn and 2) it's under a license I find a little restrictive. So I'll do it on my own. (Some say I say that too much ;))

Today I began by checking out how to grab the webcam stream. This turned out to be much harder than I would have expected. In fact, after a few hours I've all but given up. It seems the only way to grab the stream is through an ActiveX control provided by WowWee. However, I can't even seem to find the file. I tried going through the rtsp interface the API specified, but with mplayer and kaffeine it failed. I ought to try VLC, but I don't have it installed right now.
So after my fail at retrieving the stream I decided to see how fast I could poll the Rovio to grab images. The API provides a facility to retrieve one image at a time (http:///Jpeg/Image0001.jpg) and I used that. I wrote a little test program in Python to see how fast I could poll this and surprisingly I was able to poll it at 24 fps for the max resolution and 30 fps (the max refresh rate of the camera) for the lowest quality. However, if I read the image at every frame (when I say read I mean just read, not even decode the jpeg) then it only runs at 15 fps for the highest quality. 

So, likely 15 fps will be more than enough. I imagine any computer vision algorithms I apply to the images take much longer than 1/15 seconds, so I think the polling method will work fine. Another reason polling is good is that I can run the poll at whatever rate is necessary at the time, including varying the rate depending on the circumstances (though I don't really know what good that will do me).

PS: The code for this project can be found on googlecode at http://code.google.com/p/roviopy/

Here's the first post!

In the past I've never been good at the whole "writing" thing. Hopefully this will allow me (force me) to get better about it. Now, why would I want to make a blog?

I decided that I needed to start a blog. Mostly because of OriginDB. I really think this project could be something great, and if it is, I need to document it better. That's the number 1 goal of this blog.

Reason number 2: I am taking this summer "off" to work on some personal projects. I have at least two or three planned out already. I want to create a "SmartKeg" a la KegBot, and I want to create a good Python interface to the Rovio robot. Both of these projects I could see other people liking to know how I did it, so I'm going to try to keep a record on this blog.

And finally reason number 3: I love homebrewing. Homebrewing to me is like FOSS, it should be done out in the open. I am going to use this blog to document all of my recipes as well as my methods and the outcomes.

I am really looking forward to trying to keep this up. Let's hope it works!