Messing and Meshing with FEKO

I have finally gotten around to doing some preliminary electromagnetic simulations to estimate the expected backscatter from a crop field. After looking at the PolsarPRO simulator code and being told by the author it would be pretty hard to adapt to X-band I looked at other options for producing electromagnetic simulations of crops.

One of the options is HFSS which uses finite element model based EM simulation. It can produce RCS of extended targets but will require modifications for SAR simulation. There has also been some work done using FEKO. I have already done some 2D plant model building using Python. Now it is time to send them into Blender and make something optically pretty.

There is ngPlant to draw inspiration from. Where as a lot of work has been done on image formation with standard light , I have to break new ground in easy simulated image formation with SAR.

So far I have loaded a cylinder created in blender and exported to STL as a mesh into FEKO LITE, which has severe limitations on simulation size. Just as a test case the cylinder seems to have a much greater RCS in vertical compared to horizontal.

Conceptualizing the YouCharge - Solar + Bike powered Charging Station

Last night Derek and I put our heads together and finally came up with costing and timing for the human powered mobile device charging station, temporarily dubbed YouCharge (uCharge , iCharge and WeCharge are also feasible). We decided that we can't rely on people to keep our battery filled and a set of solar panels was added.

I provided basic system design in terms of major components required and Derek did some skillful spreadsheet manipulation and timing estimates. Overall we came in just over the small grant threshold. The station will sit somewhere in Rundle Mall and attract people with energy conserving bright colours (as opposed to music and flashing lights) and possibly sweaty gym rats. There will be opportunities to competitively sustain high power generation ( high scores) and have live competitions as a spectacle sport. The data from the generator output, battery charge levels and devices being charged will be logged using an arduino + embedded linux ( let us say hawkboard). This data stream will be published live via city lan and visible  to all.

We are not breaking fresh ground here. Suitable machines in hongkong gym were converted to produce electricity. ABC had a show on PedalPower. In China outdoor gyms with free excercise equipment abound. May be Adelaide can slowly switch from energy hungry fitness facilities to energy producing ones. Adelaide Hackerspace will lead the system integration and we should be ready for the Format Festival next year.

Going big and going small - AWS and Matlab for Beagleboard

Last night I had a bit of a stroll along the Amazon EC2 alley. Started up a Lucid instance and checked out orfeo toolbox into it for build testing. Nice and easy, except for bits with private key setup and such. But I have gone through password-less SSH with beowulf setups and even more recently using a Launchpad account, went through that completely unfazed.

Next stop was setting up a few Hadoop nodes and running a scripted word counter using Pig. I left the nodes running and racked up 80 equivalent hours, now to wait for the bill. Once the I figure all this out I will attempt run more parallel tasks using Java native features like JAI and the Orfeo Java bindings. Twitter seems to use Hadoop with native libraries performing compression - LZOP. Interesting point about parallel tasks being data bound, parallel image processing tasks given sufficient CPU resources should then work faster on block based compressed formats such as JPEG2000. Just need sufficient resources to test this out. Perfect use for EC2.

Then I went small and looked at the awsome work Mathworks is doing in leveraging open-source to add value to their product which is heavily ingrained in the engineering world. In the process they have made a fair few Eclipse enhancements which all of us can enjoy - Target Support Packages. With all this work developing a quadcopter control using the beagleboard might just become a join the dots project.

Arduino + Beaglebord + Other bits = Autopilot

So I have had a minor set-back with the el-cheapo motors on the quadcopter. No surprises there. Time to chin-up and get better motors and start building the second iteration. This one will feature stereo vision, barometer and the razor imu for positioning instead of the 3DM GX2. I am about to test the beagleboard to arduino connection over i2c, I will have to ensure that I attach some level converters this time to isolate the 2 voltage levels and have reliable operation.

I think the razor IMU will start life hooked to an Xbee and strung down from my hand flown co-ax. It is much lighter than the microstrain box and the little heli should be able to lift it. Both the xbee and the razor operate at 3.3 volts so no level shifting needed, the heli seems to provide some 4.2 volts which is rather odd for a lipo pack.

Helping with the lift calculations is this little tool. With a 1400kV motor i can turn bigger propellors and possibly prevent burn-outs. Better order some more el-cheapos with ESC just in case the controller is toasted as well.

Toasted motors and KNN classifiers

More proof that I should stop obsessing on the Quadcopter and focus on my PhD and possibly Orfeo Toolbox. I am just getting started with the risks in playing with real life hardware. Today we ran our 5000kV motor at full-throttle for a few seconds - under careful supervision of the folks in the electromechanical lab. The motor overheated and burnt out producing a lot of heat, smoke and molten solder . The wires heated so much the joints melted, cutting off power before anything actually caught fire. I can explain this away in terms of lack of adequate thermal overload protection. In what looked like a wind tunnel test - the motor kept running while producing smoke vortices underneath, I was typing 'h' away at my arduino console to make it go faster rather than documenting the great event.

Otherwise the workshop  has done a fantastic job putting together the frame and attaching the propellor hubs to the motors. We have 3 variants of propellors - 12x8, 8x6 and flimsy high speed low pitch helicopter ones. The next iteration will use thermistors to monitor motor temperature and cut-off when overheating is detected. LiPo charge level can also be monitored with the arduino ADC's. More code for the arduino needs to be written then. No more simple bit-bang PPM. I am also contemplating getting some lower kV rated motors to turn some of the bigger props.

On the more productive and less risky side I pulled some code published in the ITK Journal to perform KNN classification into OTB. Hope I can soon get some screenshots of KNN in action in OTB-Qgis.

Mobile Monday and Angel Financing - Risk Averse INC.

I went to my second mobile monday today. There was someone showing off that big iphone - that is an iPad and will not deign with a link (shall we call it sour grapes).

Then there were a couple of interesting talks from Innovate SA and SA Angels Financing. There was some mumbling about false starts and baby steps from the government before innovate SA was formed. Then they talked about angel financing and how 42 out of 43 proposals from start-ups got shot down.

I had a brief chat with Joe regarding AR Games and hustling university resources to build the quadcopter. Given Google 1st iteration was built is Stanford labs and the initial PageRank patent was assigned to Stanford - I have good precedence. Sadly some Universities kill the goose that lays the golden eggs by trying to quickly recoup profit and starve the growing enterprise of funds, or even worse not let outside investment come in and slow down the pace such that the start-up cannot out compete people hiring staff on Elance.

The last clencher, ideas are cheap ... implementations are costly. Here is today's idea, snake jointed twistable lenses (much like the concertina ones in old cameras) to allow realignment and better self-portrait shooting on a night out. But then all the misaligment in hand-extended-in-front-of-face is the fun.

When instruments turn nasty - yield measurement non-linearity

Last week I visited the farm manager at Roseworthy Agricultural College. Most of my work with SAR and crops has been done here. The college farm practices precision agrculture and collects telemetry from harvesters to do yield mapping and produce fertilizer application prescriptions for the next season.

He showed me some yield data from 2009 where there was marked variation in the yield (tonnes/per hectare) depending on the speed at which the harvester was travelling. 2 operators drove the harvester at different speeds and this caused a variation. Fortunately past data I have worked on was obtained by a single operator. Obviously the variation indicates a non-linearity in the flow measurement hardware.

So I went back to my old friend , Gaussian Mixture models and isolated the 2 different working speeds (combines have different optimal speeds). Then plotted the yields obtained at different speeds and sure enough there was trending againsts speed, on top of the standard infield variation the yield mapping excercise is trying to capture. This can be fixed by mathematically recalibrating the flow sensor and detrending the slope so that yield masses show similar variability no matter what speed. To absolutely calibrate the system a value for the total yield obtained in the field is needed.

AMD vs NVIDIA and some NESTing for SAR

While nVIDIA provides backward compatible OpenCL drivers. AMD in opposition to nVIDIA who supports DirectCompute even in GeForce 8 series (8400 GT and up) for a long time ago, forgets about older than HD5000 series. I managed to get OpenCL eigenvalues kernel tested on my other machine but fell flat on my laptop with a 3670 ATI.

Some work by Orfeo Toolbox guys has recorded large performance gains in non-trivial (i.e not pixel by pixel) operations using GPU options. The eigenvalue problem is typical in SAR analysis and I would like to implement it on the GPU.

Talking about SAR, first there was BEST (Basic ESA SAR Toolbox), now ESA is funding development of NEST (Next ESA SAR Toolbox). The product so far looks impressive , Java based pulling in all the goodies including NASA WorldWind. There are plans afoot to include the DORIS InSAR processor as well.

DORIS as such is very script based and difficult to use properly. Hopefully providing and easy interface will open-up more INSAR processing options.

Bringing Colour to Heights - Quadcopter shopping

So the University has finally reimbursed me for all the quadcopter parts purchase and it is time to shop for new parts for the 2nd version. All the electronics are fairly affordable. The major effort will be in the control system coding, but I found this at the University - that indicates a core of expertise in 3DOF quadcopter control, just need to extend to 6DOF.

On the other hand I have got some more impetus to do a few more filters in OTB-Qgis and even a special project in Orfeo Mantis to jot things down. The easiest thing to do was hillshading from Emmanuel's code. I chose a bit over the alps to show some colours, auto-detection of min/max in data can be enabled to obtain more variety.

SVM with multiple polygons - it is more fun together

SVM is a classic supervised classifier, but as with all such techniques the output depends on the training set provided. My initial OTB-Qgis SVM used each polygon in a shapefile as a separate training sample and was not ideal for providing extensive training data. The access to vector layer attributes via otb::Datanode makes it feasible to assign multiple polygons the same class value, there is always the fallback to 1 polygon per class if there are no attributes with the polygons. Here are some comparisons with 4 polygons and the results by using 1 polygon per class and all polygons with the same attribute being assigned to 1 class. The 1 polygon per class allows us to distinguish cultivated vegetation vs natural riparian vegetation and 2 types of rocky/bare areas. While the multiple polygons per class aggregates the vegetated areas and bare areas into 2 classes.

The beagle has 2 eyes - OpenCV Stereo on BeagleBoard

I have the ambitious aim of allowing my Quadcopter to see in stereo. So recent tests are being conducted of a suitability of on board stereo processing via OpenCV. So far the unoptimized version of OpenCV makes this really slow and impossible to do in realtime. I just got the last day of author registration in for IGARSS as well, I hope it was on time.

Some USB devices arrived from deal extreme - USB GPS running at  1Hz / 38400 baud and a Ralink Wireless-N dongle which does not have prebuilt drivers in Linux or atleast not one that autoloads with the USB device. I will investigate the wireless later but for now it frees up a slot to try out stereo - so here is the rig.

The gstreamer capture and opencv stereo_match both work as expected and it takes about 300ms to grab frames and 12300 milliseconds to form the disparity map with default settings. Much can be improved in the opencv front to reduce the time required for processing. As a comparison my laptop using the same set of tools - Gstreamer for windows with the ksvideosrc as frame source and OpenCV 2.1. The frame capture speed was 250ms and the disparity map was produced in 300ms.

So a realtime stereo vision based quadcopter may not be possible, but data capture and indoor map building with post processing is definitely feasible. I got a quote for the Hokuyo laser scanner, though significantly more expensive than the stereo rig ( few hundred thousand yen) it has larger field of view and more reliable point cloud production independent of features on the target surface.

Outlining in Lyx - Papers for IGARSS

My external spinning platter disk is having a fit. I will stick it in the fridge and pray that I can recover some data off it. Should not have dropped it so much and made triple copies of AGRISAR data.

Some more work I have been doing with Lyx Outline on Elance and trying to write up a paper on rangeland analysis for IGARSS with TerraSAR-X and ALOS-PALSAR. Lyx can be quite handy for writing IEEE papers from Latex templates. The outlining tools help you reorganize content and rename sections.

I have also been working on parameterizing surface roughness measured with a pin-meter into a Gaussian random generator process with exponential correlation function. More fieldwork was carried out involving driving around, photographing and collecting samples. I hope one day all this experience can be presented cohesively.