We have moved! Please visit us at ANTHROECOLOGY.ORG. This website is for archival purposes only.


Feb 29 2012

64-bit Python Computing

Recently I ran into a memory problem running large point cloud arrays through Python and Numpy.  I quickly determined that I was asking Numpy to work on massive arrays that were exceeding the limits of the 32-bit Python process in Windows.  I came up with a workaround whereby I truncate the UTM X-Y coordinate information so I can store the numbers as 32-bit floating point values without losing precision, then add the extra numbers back at the end.  Basically, I translated the X-Y coordinates (352845.49 4346713.91 --> 2845.49 6713.91) then back again to the original UTM values after computation.  This was OK, but I wanted to overcome the 32-bit limit in Python.

There are unofficial 64-bit builds available here, but I wanted to try something established.  I got one of our machines running dual-boot Windows 7 / Ubuntu 11.10 64-bit and compiled all the Python, Scipy, and Numpy libs in Ubuntu.  These builds are inherently 64-bit because of the 64-bit OS install, so there are no issues with addressing large arrays of data.  Back to work!

Jul 18 2011

XBees Again

I think I have fixed the XBees, again, maybe…

I wanted to get our tablet laptop up and running again as a Hexakopter flying machine for the field – especially since I got the new Pentax WG-1 GPS camera in the mail today (I’ll post on that soon).  This laptop had already been running Mikrokopter-Tool v1.74a, allowing us to do 3D waypoint runs, but the XBees were not functioning at all.  I also had it in my head to install a SSD hard drive in this old laptop to give it a new lease on life – what better opportunity to try a fresh setup! 

A quick note to anyone that has found their way here with their own XBee woes, we are using XBee Pro DigiMesh 900 modules.  This post discusses the (hopefully) successful configuration of a pair of XBee Pro 900’s each mounted on an Xbee Explorer USB.  In a previous post, Xbee Solutions?, I suggested that it is necessary to have an Xbee Explorer Regulated on the MK end, but it seems that may not be necessary based on the results described below.

I got all the standard drivers and software installed and running (XCTU and  UART drivers) and plugged in the suspect Xbees.  Windows 7 said it correctly installed the new hardware, but when I opened up MikroKopter Tool I could not get any XBee communication. AAAAAAAH!

Back to the internet, I found this long thread about Xbee problems that offered promise: http://forum.mikrokopter.de/topic-21969.html

Taking from the thread, I set up two XBees on the same machine in two instances of XCTU to be able to effectively range test and compare parameters. Why had I never thought of that!? I read the modem configurations from each unit – mostly noting anything that was other than the default and confirming the baud rates were set correctly.  I quickly noted that the Modem VID numbers were different and read from the help dialog: “Only radio modems with matching VIDs can communicate with each other.”  One XBee was set to the default and another was set to a specific number.  I didn’t remember making this change but decided to set them both to the same number.  The range test was now working perfectly (see post picture).  Back in Mikrokopter Tool I was back in business with wireless telemetry, but I still couldn’t transfer waypoints.  I kept getting that ‘Communication Timeout’ error.

I tried another suggestion from this  post  in the same thread and manually adjusted the Destination Addressing fields on each unit.  I noted the high and low serial numbers for each unit (SL and SH) and manually configured the  high and low destination addresses to point at each other: XBee1 DL = XBee2SL, XBee1DH = XBee2SH, and vice-versa.

I flashed these settings, booted up MikroKopter Tool and was wirelessly transferring waypoints and receiving telemetry with no problems.

Of course, now we just have to see if it’s actually going to work in the field!

Next up: playing with the GPS camera!

Mar 14 2011

Getting Friendly With Python

We made great process today on our Python coordinate transformation algorithm. We are using scipy and the optimization module to find the best approximation for our transformation parameters, and are almost done finding a solution. Much thanks to Jonathan for being super helpful!

Feb 11 2011

Rising Popularity of the R Programming Language

According to a recent analysis of the search hit popularity of the top 100 programming languages, the R Statistical Computing language, has surpassed both MATLAB and SAS.

I first read about this from the Revolutions blog, a blog dedicated to posting news and content about R, and was happy to see from the survey report charts that the free R software has such relatively high popularity compared to similar languages.  It is worth noting here that the popularity difference is slight due to the fact that this survey counts many languages that are more popular than either R, MATLAB, or SAS. R (#25) had a popularity of 0.561%, MATLAB (#29) 0.483%, and SAS (#30) 0.474%.  Meanwhile Python (#4) has a popularity of about 7%, C (#2) about 15% and Java at #1 with about 18.5%.  The Revolutions blog also makes the important point that the methods used to compute these stats may be a bit controversial, but the stats still serve a purpose.

I first learned R from taking a graduate level statistics course at UMBC, Environmental Statistics 614, and have developed my skills with the programming language to help with data analysis and preparing graphs and figures for papers.  I used R to perform the data analysis and generate the non-map figures for our first paper on Ecosynth and will continue to do so for future publications.

I have only used MATLAB to execute a camera calibration program for my Computational Photography class last semester and I learned a bit of SAS programming for my Multivariate Statistics course last year.  I think both have their uses, but I am really fond of the relatively light-weight size and 'cost' of R.  I am also interested in adding in the scientific and numerical programming functions of Python, SciPy and NumPy.  The SAGE project utilizes SciPy and NumPy to establish a robust free and open-source alternative to for-pay analytical tools like MATLAB, and is also increasing in popularity.  

Free open-source revolution!  This makes me want to put up a post about open-source GIS software...