Embedded Edge

Not bad for a birthday party.

2012-02-18T16:13:00.000-10:00

Lisa's birthday party featuring Virgin Mary, fire-spinners and a lot of drunk physicists. Thanks to everyone who showed up! Many thanks to all the performers!

Happy birthday sweetheart!

i915 finally (mostly) stable

2012-02-13T13:48:00.000-10:00

Its been two months since I got my UX31 zenbook, and nearly a year since the sandy bridge CPU/GPU combo chips hit the market. Initially the linux support was very much lacking: with the rc6 powersaving enabled I was getting random graphics glitches and reboots, without the power-saving options I was getting 2.5 hours of battery life plagued by less frequent reboots.
This all changed with the a string of commits by Daniel Vetter to the 3.2.6 kernel tree. Having compiled this kernel I did not experience any more crashes, graphics glitches, and the battery life is now solid 7 hours.
I would like to send a warm thank you to Mr. Vetter for making my laptop usable for software development.

Laptop Ants

2012-02-12T13:38:00.000-10:00

I turned on my shiny new ASUS zenbook this morning only to find that it got very buggy. Around 50 very tiny ants spilled out of the cooling vents instantly, followed by a steady stream of about 10 a minute. One might make an argument that the are doing me a favor by cleaning out the dead skin sells and microscopic bits of food which get trapped in the keyboard, however spilling a cup full of ants during say a meeting with my PI might look a bit unprofessional....
In order to remedy the situation I am going to try to run the cpu/gpu at full speed and frequency until its toasty 89C. Hopefully ants will get the hint and decide to abandon their new found home. Wish me luck.

cdce62005

2012-01-29T16:02:00.001-10:00

Clock distribution for ADCs is hard. Especially so if your design requirements include less then 20ps jitter and more then 10 channels. Luckily IC engineers at TI came up with pretty awesome of the shelf solution. CDCE62005 is a 5 channel LVDS compatible clock generator/cleaner, which promises1ps jitter, and up to 1.175 Ghz operation, and easy SPI control. Furthermore at 20$ a piece it wont break your budget.
Cajipci parts are mostly picked out, as long as the specification review goes well, we will finish schematic capture and move to layout in a couple weeks.

CAJIPCI

2012-01-19T16:04:00.000-10:00

Another semester, another set of responsibilities. This time I along am tasked with developing a CPCI circuit board with capable of programming, distributing a clock to and possibly triggering a neutrino detector.
I have written PCI drivers and firmware in the past, however this is my first attempt at creating a circuit board. You can follow my progress at: http://code.google.com/p/mtc-cajipci/
The board name is CAJIPCI which stands for Clock And JTAG In PCI. I tried very hard to come up with a witty acronym, but this is the best I can do.
So far all I have been trying to figure out the circuit board CAD software called PADS. PADS is a very nice and complete design suit, however I have a couple gripes with it:

Only runs under windows. It would be nice to use eagle, but we don't have the license for it.
As with all design software stability leaves much to be desired.

Hopefully if this goes well our group will have a working detector by the end of summer. Wish me luck, and till next time.

Lessons learned from continuous integration.

2011-12-14T03:30:00.002-10:00

I spent a better part of my semester studying continuous integration. I started by participating in a team exercise to build client software to communicate with a Wattdepot server. Then each teams switched and reviewed each others work based on the documentation, issue tracker, build server statistics, and of course the quality of code itself. Finally we extended the other teams code base by adding additional functionality.
Original code was completely synchronous: once user entered a command he was presented with the output and redirected back to the prompt. The new functionality however had an asynchronous component. We implemented the following additional commands:

monitor-goal : Monitors power consumption and output whether it exceed the baseline value.
set-baseline : Allows user to set the baseline for monitor-baseline.
monitor-power : Monitors power consumption and outputs it to the screen with a time-stamp.

Monitor command executed in a loop at a given interval, waiting for user to hit the return key, while set-baseline returns immediately after the baseline is set.
I found this portion of the exercise to be my favorite. Not only was I working on top of a well build system, but the problems at hand were no longer trivial.(In fact I think we might have over-complicated the implementation.) There were two main challenges in this project:

set-baseline and monitor-goal need to communicate the baseline values.
monitor commands need to run asynchronously and at a given interval, while waiting for user input.

We solved the first problem by implementing a singleton class which maintained a map of baselines for various location we were able to monitor. The second problem was solved using threads. Once the input to the command was processed, main thread would start a worker thread and then sleep and periodically while checking for user input. The worker thread on the other hand would sleep for a specified interval, perform its task and then go back to sleep.
I found the other teams code base well documented and easy to understand. In order to make my new command available to the system all I had to do was change one line! Makes me feel foolish for implementing internal reflection in our code. The only complaint I have with the code-base, was the command unit testing. All tests for commands were inside a single class. This works well, if there is only one person working on the commands, however with a team of three people editing a single file we were bound to have version control nightmares, so the tests were refactored.
I mentioned the three pillars of software engineering on this site before, and I will mention them again. The first two are fairly easy to test: all you need to do is try to use the software. The last one however requires some work. In order to check if a software project is developer friendly one must dive into the code and documentation, and piece together what the original developer was thinking. This can teach you quite a bit about software development, or make you long for a new career.
Working with third party code is always an adventure. While most open source projects come with a well groomed code-base and excellent documentation, some of the more obscure projects will make you wish you implemented them from scratch. Luckily this time developers put a lot of work into the project, and it shows by how easy it was for our team to make it even better.

Three pillars and the quest for intelligent group software development

2011-12-01T23:19:00.001-10:00

I mentioned three pillars on this blog before. They provide a very simple methodology for judging quality of a software project. My software engineering class is currently covering continuous integration so my hale-aloha team decided to apply the three pillars along with some concepts of continuous integration to our software projects. I attempted to analyze a wattdepot project located here. This software project had the same specifications as my wattdepot-cli, however the implementation is entirely unique.

Does the system accomplish a useful task?

I was able to install the software by downloading the distribution package from the projects download page and running the provided jar file. On execution I was greeted by a friendly message:

Connected to the Hale Aloha WattDepot server.
Type help for a list of possible commands.
cli >

The help command provided a nicely formatted help message describing each available command. I was able to execute all of the command, and the data returned was in the ballpark of what it should be. The only problem I encountered with valid input was that the daily-energy, energy-since, and rank-towers commands did not support current date as the argument.

On the other hand I found that the error checking on the input could use a bit more work. Using Wireshark I found that the program still made a request to the server even if I pass an argument to the future(2034-11-30), or an argument which matches the regex but makes no sense as a time stamp(2011-11-88). Instead of validating the dates on the client side, this project uses the server as the error checking mechanism. On the bright side if a wrong number of arguments was passed to the program, it behaved as it should, by printing the associated help message.

Overall I think this software project produced a nice and usable program. Unfortunately the time constrains associated with the development resulted in a couple rough edges.

Can an external user can successfully install and use the system?

As described in the first question I was able to download the distribution archive from the downloads page. The user guide included installation instruction and the software requirements for the package. With Java build once run anywhere model I was able to get the code up and running with minimal hassle.

Furthermore the version number of the build was attached to the jar file for easy identification.

Can an external developer successfully understand and enhance the system?

Developer guide is packed with helpful info. It provides guidelines for submitting code, supplied a links to a build server, as well as requirements for code submissions. Furthermore developer guide provided instructions to build Javadoc documentation.

Documentation build without a hitch and it looked complete and thorough. In fact it was so clear I was able to understand the inner-working of the program just by looking at the generated documentation. All of the class names indicate their purpose. Furthermore a standard command interface provides a very easy to implement additional commands.

Software is complimented by a large array of tests which provide 83% test coverage according to Jacoco. Tests covered all of the relevant functions and were almost always well partitioned. However the test for the current date are missing from the source, which I imagine is the cause of the errors I was reciving in question 1. It seems that while the test coverage is almost perfect, however it may be beneficial to re-partition the test cases.

After examining documentation I build the system from source via the directions provided in the developer manual. It build without a hitch and ran just as the provided jar. Furthermore the system verified successfully using the ant verify directive described in the documentation.

At that point I finally dove into the code. I found that the code base was well commented and followed the required guidelines. Methods and local variable names were well selected, and descriptive. There were no god classes, and no dead code.

Next I examined the issue page. I found between the two developers the work was divided evenly, with one developer working on the commands and the other working on the command interface and command processor. I would think that a novice contributor could use the Issues page to determine which developer would be the best person to communicate with on a specific topic.
Finally I checked the continuous integration server. I found that all but one of the commits to the source were done for a specific issue, which goes with the main methodology of the continuous integration. While there were several days(Nov 23 – Nov 25) where the build was broken, it can be attributed to a hale-aloha server crash.
I think that the developers put together a well build ecosystem for software development, and set an excellent example for new developers. I don't consider myself a strong Java developer, non the less I was able to follow the development flow, and software design that my classmates put forward.

Wattdepot cli

2011-11-28T22:32:00.001-10:00

Having gotten my feet wet with Wattdepot, I just could not get enough. I and a couple of my fellow grad students decided to, create a simple command line driven client to a Wattdepot server. We made the core of the program use internal reflection which made it extremely easy to add extra functionality based on the command interface. Having never played with internal reflection before, I had a hard time following my colleges core code, however I found it easy to create commands based on the API.
Having worked on the team based project before, we found it fairly easy to integrate myself with the rest of the developers. We managed to develop a complete system with good test coverage, and usable documentation.
In order to further integrate our team further, we used a Jenkins build server. This allowed us to quickly catch problems in our code without having dig through the revision history. In combination with JUnit testing allowed us to maintain a vary good build history with only a single failed build, during the development.
In the end we managed to put together a nice software package. Our program was able to:

Display current power consumption by a tower or a lounge.
Compute the daily energy use by a tower or a lounge.
Compute energy consumed by a tower or a lounge from a user specified date.
Rank towers based on energy consumption for a user specified time interval.

Well there you go. To do efficient team based software development you need the right tools and the right team.

Wattdepot fun

2011-11-07T21:06:00.000-10:00

A few days ago I discovered an interesting software project called Wattdepot. It aims to monitor energy consumption habits, by combining output of any number of sensors, in one place. This project is based around Java daemon which monitors communication with sensors, and a client side library for communication with the server. I decided to put my Java skills to a test and write a few simple apps for communicating with the Wattdepot server.

By the end of the day I ended up with six programs:

A program which lists all data sources and their descriptions.
Compute the latency for all available source.
Build and print the source hierarchy.
Calculate the energy usage for the previous day.
Compute the peak usage for the previous day.
Compute the average energy usage.

I think between these programs there is enough functionality to create a fairly complete resource usage monitor.

The only problem I encountered during this exercise was the multitude of calendars available in java. There is the XMLGregorianCalendar which is used in the wattdepot API, there is a GregorianCalendar which shares a lot of functionality with its XML counterpart. Finally there is a Calendar type which seems to be a super-set of the GregorianCalendar.

Finally I found a small bug with the time synchronization between the sensors, server and client. A lot of the time when I request a set of sensor data which spans an interval starting from the current time, I get a BadXML exception, since the current time may be in the future for the sensor or the server. I am used to dealing with a clock skew on the order of a few tenths of picoseconds in the embedded systems I work on, so I am not sure how one would remedy this issue. One workaround I found was to use NTP on my client and only request data up to 20 minutes ago; ever since then the exceptions dissipated.

Well there you have it. My small excursion in to wattdepot. If you got some free time and would like to know more then you ever want to know about java calendars, check them out. See you next time.

Hawaii Power Crisis

2011-11-01T12:00:00.001-10:00

As with most infrastructure of Hawaii, Power production was never really planned. With the population growing uncontrollably, the energy generation is struggling to keep up the only way HECO finds profitable, by burning more oil:

http://www.oilcrisis.com

Things have gotten so bad that even the military, who are generally not know for their green thumb, has begun constructing renewable power installations such as the wind mill station on the north shore of Hawaii.
A good question is where is all of this energy going? Here are a couple of chart freely available on the internet:

Energy consumption breakdown for Watanabe Hall.

Home use energy breakdown.

Above we have a breakdown for a typical workplace(this happens to be where I work), and a typical house home. What is mind-boggling to me is the amount energy that Watanabe Hall spends on air conditioning. This building serves as a headquarters for the physics department at University of Hawaii. We have a small cluster which is running jobs 24/7, lots of scientific equipment which is known to suck down power, a machine shop which is staffed and running 8 hours a day, and even a free electron laser which occupies most of the first floor, and considering the amount of radiation it produces, probably sucks down a considerable amount of power. Yet all of these energy sinks combined don't compare to the energy consumption of the AC.

The second pie chart represents energy consumption of a typical Oahu home. It is clear that the water heater is the biggest culprit in energy consumption. This is not surprising since water has a really high specific heat.

So now we have picked out the most vital areas for improvement both at home and at the workplace, but how do we fix this. Lets start from home; The solar water heater is an obvious answer, however an inconvenient one if you like to take showers at night. However if one examines an average water heater, you will soon find that most of the time it is simply heating the water for no reason, in order to maintain some amount of hot water for immediate use. Perhaps an answer at home lies in a combination of a solar water heater along with a high BTU electric water heater which is only on when you need it.

As for the office the problem is significantly harder. While slapping a whole bunch of solar cells on the roof might sound like a good idea; I believe that a redesign of the way we do air conditioning is required. There have been rumors of a project involving using ocean water to cool downtown building, which sound like a step in the right direction, however it has not maid it past the planning stages.

Make sure you turn all the lights off when you leave. Till next time....

Interview Question Brainstorming.

2011-10-25T02:29:00.002-10:00

Today I decided to do a mental exercise, of looking at 5 interview questions, which any Java software engineer should be able to answer. This is only my interpretation, since I am by no means a java software engineer, however since a lot of my computer science curriculum is in Java this is what I managed to pick up:

1. Is Java typesafe?
For years I followed the argument between the Java and the C++ fanatics. For years the C++ camp has been convinced that Java is too slow and memory intensive, while the Java camp has argued that C++ is not type-safe, and more bug prone. Now that I learned to write in both languages I found that both claims are overstated. Consider a following code segment:

public String concat(List strs)
  {
    if(strs.size() > 0){
    return (String) strs.get(0);
    }
    else{
      return null;
    }
  }

There are a two problems with this code. First the function argument List is a container of unspecified type. This means that it is absolutely legal to call this function with an argument of List<Integer>, however at runtime the code will crash. Furthermore null is an object is an member of every time, therefore an explicit check for the null object needs to be added at every entry point into the perfect "typesafe" Java code. Short answer NO. Java is only as typesafe as the developer.

2. Whats an IDE and how is it different from a build system?
   Last few months I struggled my way through learning Eclipse. At first I was repulsed by the complexity, and the lack of vim shortcuts. Now however I am pretty comfortable using Eclipse as a Java development platform, because it brings a friendly interface to most of the Java tools.
So what is an IDE? The right answer is: code aware editor which integrates project management, building testing and version control. The tempting answer is: anything better then notepad.
How does it differ from a build system? A lot of programers think that the IDE is the build system, but for the most part they are mistaken. Almost all IDEs are a fronend to a build system, be it make or ant. Why is this important? Because not everyone uses the same editor, but everyone who is collaborating on a project should be using the same build system.

3. Whats revision control and what is it used for?
   Picking a revision control system is one of the first important decisions that any collaborative software project makes. On the other hand a lot of developers view revision control as a way to roll back form the mistakes they made in the current session. Yet version is so much more then that. First of all it is the only sane method to do collaborative software development. Can you imagine how hard it would be to maintain a project like Apache or the Linux kernel if everyone relied on patches? It also allows developers to support multiple versions of the same software through branches and tags, allows for integration with bug tracking and documentation systems and much much more.

4. How do centralized and distributed revision control systems differ?
   Distributed version control is a hot new topic in software engineering. It allows for collaborative development on a truly massive scale. Git for example powers the development of the Linux kernel, with more then a million lines of code and countless contributing developers. Centralized version control system have a single master branch. Collaborative development in such a system is done by all of the developers committing to this branch thus moving the development forward. Distributed VC systems like git allow for multiple master branches, in fact they allow for every commit/revision to be its own local branch. This for example allows developers to put away revisions of code even if they don't have access to the centralized VC server. During the release branches are merged together only to be branched again for the next release.

5. All software testing falls into two categories what are they and how are they different?
   Software testing suits such as JUnit and Apache::Test allow programers to write a set of asserted test to make sure that the changes in the source tree don't break the build. There are many methodologies in testing such as Black/White box testing and certain software project even choose test driven design as a development strategy. Regardless of the methodology these tests fall into two categories Validation and Verification.

Validation test make sure that software is functional for a specific purpose. This usually involves unit tests on the internal data structures and algorithms.
Verification test make sure that software adheres to the specifications. This usually involves behavioral test on the software package.

So here are my $0.02 on how ace your next software engineering interview. Till next time.

Set Yoshimi free.

2011-10-20T00:39:00.000-10:00

Today I decided to release Yoshimi to the robocode community under the LGLP license. Having always used my private code repository I decided to experiment with Google project hosting instead. Now, I used a lot of private code repositories in my career, and I run a local subversion repository at home for all my personal projects, but none the less I was very impressed with what Google project hosting had to offer. The main features which sparked my interest was the bug-tracking system and the wiki. At home I use trac to provide both bug tracking and the wiki. Trac integrates very well with my version control system of choice, subversion, by allowing submitter to close/alter bug tickets and reference the wiki. The only downfall of trac is that it need to be rerun after every commit, which I usually accomplish that rebuilding of track as a cron job. This means that the changes to the source tree don't make it to the bug tracker/wiki until the cron job runs. Under Google project hosting however, the changes to the wiki and the bug tracker appear instantly with every commit, which I imagine alleviates confusion with the development team.
The rest of google project hosting features are pretty straight forward. There is a websvn rip off for browsing source code online, encrypted connection to the repository, a generous quota for the download section. Most importantly Google has made sure that their project hosting environment is highly integrated and very easy to use. I would recommend Google project hosting to anyone who want a quick and easy way to host a small/medium project.
Yoshimi source can be found here.

Yoshimi

2011-10-10T22:54:00.003-10:00

   I spend the last couple of week designing and writing a robocode competitive robot Yoshimi. The name comes from the Flaming Lips song Yoshimi Battles the Pink Robots. Implementation of this robot is entirely my work, however I used the build system from pmj-daCruzer in order to simplify my project.
   Yoshimi attempts to confuse her opponent by staying still until the opponent fires its gun. Once she detects that, she will attempt to move away from the bullet's path. For targeting this robot maintains several previous positions, and once she collects enough data she will attempt to calculate the future position of the opponent and fire.
   The Radar on Yoshimi is design to maintain the lock on her opponent in order to maximize the collected data for targeting. Once the robot is detected the direction of the radar is reversed for the next sweep. The problem with this approach is that it looses radar lock fairly often. Furthermore once the lock is lost Yoshimi's radar will have to travel the rest of the arc before the target is found again. However even with these downfalls, I found that this method works fairly well. While it is not possible to detect when the opponent fired, Yoshimi carefully tracks her opponents energy and if it is ever suspiciously lower then it should be Yoshimi will attempt to dodge the bullet.
   Movement of Yoshimi is design to be as confusing as possible. Every other robot detection Yoshimi will turn perpendicular to her opponent. If it was detected that the opponent fired a bullet, Yoishimi will attempt to dodge it by moving forward or backward a random amount. In order to do this move successfully Yoshimi must move to a good position with plenty of room to move around. This is accomplished by moving at least 100px away from the walls in a radial arc movement.
   By maintaining a list of previous positions Yoshimi is able to interpolate the future position of the enemy robot. Initially I attempted to do this by fitting positions with higher order polynomials, but I found that my sampling was too far bellow the nyquist frequency of movement for robots such as Spin bot and Crazy. Furthermore when fighting robots with linear movement such us Walls, polynomial fits created beats which further through off my targeting. While its rather disappointing I settled on using linear fitting which works reasonably well.
   Here are the results for battles against sample robots. All results are for a 100 round match:

against Walls wins every time. Survival: 100/100
against RamFire looses pretty badly. Survival: 2/100
against SpinBot wins but not every time. Survival 80/100
against Crazy wins almost every time. Survival 99/100
against Fire wins every time. Survival 100/100
against Corners wins every time. Survival 100/100
against Tracker wins almost every time. Survival 99/100

   Pretty nice if you ask me. The predictive shooting works well enough to show robots such as Crazy and SpinBot who is boss. Dodging bullets works well enough to take out Tracker and Fire bots. The only problem is RamFire, this robot moves to the position where Yoshimi is not able to dodge its bullets, and fires really large bullets. One possible solution to this would be to make the dodge logic run away from the robot if its too close, however I did not try to implement it quite yet.
   This is the largest software project I have ever written in Java so I needed a good testing framework to save me from myself. Once again JUnit came to the rescue. Yoshimi uses a several internal data structures such as circular buffers, and polar vectors. All of these data-structures included unit tests. Also robocode uses a very strange left-handed coordinate systems, which made writing trigonometric code very bug prone. All of the spacial calculation routines included unit tests as well. Finally robocode includes a testing framework which was very useful for getting kinks out of the more advanced algorithms which would have been impossible to test via JUnit.
    I have to say I learned quite a bit about Java and software engineering in general. I found testing to be imperative in construction of this robot. This was mainly fueled by my lack of the understanding of Java. At first I started to write this code with the intention of adding tests later ,but a few random NullPointerExeptions in the middle of the match, quickly made me change my outlook. Furthermore I started writing this robot as a superclass of the more basic Robot, but eventually gave up and ported it to the Advanced robot superclass. If I were to write a new robot from scratch I would definitely pick AdvancedRobot from the start, but I found that the difference in implementation was minimal and very well described. Overall the amount of available documentation and examples from robocode community was excellent, and the API was very clean and easy to work with. I would recommend robocode to any Java beginner.

Ant Fun

2011-09-29T11:36:00.002-10:00

As I continue my learning of java I am constantly amazed by the amount of readily available software libraries, both free and open source. Of course as with all languages, using 3rd party libraries makes the redistribution of your code a huge hassle. In languages I know and love such as C and C++ a shell script will walk through your system and find all the required software. This is great as long as the software exists on your system, however if a dependency is missing the configure script will fail to generate the Makefile and your compilation comes to a grinding halt, until you obtain the failing dependency.

It seems that java developers decided to stop playing the cat and mouse game of dependency management and instead created a build system which can take care of these semantics automatically. This build system stack consists of the actual build system called ant and a dependency installer called ivy.

Having grown up on Makefile, which is basically a structured shell script, I decided to start slow by learning ant first. In order to do that I first started with an ant script which would print a string "Hello Ant". This very simple ant script had a single target with an echo statement.

Next I played with the property directive. One thing I found strange in moving from Make was that the variables in ant are immutable. So initializing a same variable to two different values in different spots in the script, effectively ignores the last assignment.

Before trying ant with java code, I examined the dependencies for build targets. As expected ant ran the dependencies in the right order. Furthermore as with make ant was able to find deadlocks in circular dependencies.

Finally I applied my newly acquired ant knowledge to a simple java project. The project contained a single class with a main method which printed the familiar "Hello Ant". I created ant scripts which compiled, ran and generated javadoc for the code. Furthermore I created an ant script which compressed the entire project for redistribution.

I found ant to be a satisfactory java counterpart to make.While ant lacks the flexibility of running shell commands, it makes up for it by a simple xml configuration file, and compatibility with tools like pmd findbugs and checkstyle.

Till next time...

P.S: How many ants are needed to fill an apartment ? Ten ants.

Super Wallet

2011-09-21T10:42:00.001-10:00

Yesterday my wallet finally fell apart and that got me thinking about making a new one from scratch.

Now if I am going to make something that is going to reside in my back pocket for years to come I am going to make it right!

I started out with a piece of Kevlar-Nomex fabric. This stuff has a breaking strength of 500lb and is extremely slash resistant. For how tough it is however it does nothing for EM shielding. Any self respecting geek must have an RF shielded wallet, so I fixed this deficiency with a 6g layer of silver epoxy:

Needs more Epoxy.

Silver epoxy has amazing EM shielding properties, and on top of that, it provides extra strength to the Kevlar. If you want to make it cheaper, I think using regular epoxy with a layer of tin foil might work just as well. Once there was a nice uniform layer of epoxy on the Kevlar I let it dry for about 4 hours and then sewed a layer of 330 Denier Nylon to the Kevlar:

So Shiny!

Almost done with the front.

While Kevlar is slash resistant luckily it is not puncture resistant, so its possible to work it with a sewing machine. Once the the back was finished I added a 1 inch nylon strip to the outside for extra reinforcements.

Next I made the other side of the bill pouch out of Nylon fabric and strips:

Excuse my crappy camera.

Finally I attached it all together:

Inside.

Outside.

So here is my supper wallet. Till next time.

Robocode Fun

2011-09-19T03:47:00.000-10:00

This weekend I decided to put my Java and software engineering knowledge to the test, by testing out the robocode framework. This framework is a mix of a game engine and programming environment which allows the user to create an AI robot, and battle other robots in a simulated arena.
Robocode has a long and colorful history. It was first released by Mathew Nelson of IBM in 2001. Eventually IBM decided to cut development and Robocode entered public domain. Since then it has undergone several major rewrites by the open source community. Robocode has been ported to the .Net framework which allows C# and VB.NET users to develop and battle robots.
Robocode robots all inherit from tree basic robot classes:

JuniorRobot : The simplest robot which provides all game variables as a public field.
Robot: A more advanced robot with synchronous event processing.
AdvancedRobot: A very advanced superclass whith asynchronous command and event processing.

JuniorRobot was far too simple for me, and it went against all of my software engineering ideal, (No getter/setter methods?) AdvancedRobot was far to complex for the simple exercises I had in mind, so I settled on the Robot superclass. I coded the total if 13 simple robots, all of which performed a single predefined task:

The minimal robot. Does absolutely nothing at all.
Moves forward a total of 100 pixels per turn. When it hits a wall, it reverses direction.
Each turn, moves forward a total of N pixels per turn, and then turns right. N is initialized to 15, and increases by 15 per turn.
Moves to the center of the playing field, spins around in a circle, and stops.
Moves to each corner of the battlefield.
Moves to the center, once there moves in a circle of 100px.
Picks an enemy and follows it.
Picks an enemy and politely follows it at 50px.
Moves away from the closest enemy.
Does not move, rotates the gun and fires when a target is in the cross-hairs.
Does not move and only fires when a specific target is in the cross-hairs.
Does not move, rotates the gun and fires when a target is in the cross-hairs. The bullet power is proportional to the distance to the target.
Track a specific enemy with the turret.

Everything was going swimmingly until I got to robot number 6. From that point on I started to wish that I used the AdvancedRobot superclass instead of Robot. With asynchronous movement it is possible to move and turn at the same time. This would have made moving in a circle a lot easier. At robot 13 it became clear why competitive robots use AdvancedRobot as the superclass: Robot can't track the target with the radar and turn its turret towards it at the same time! Furthermore Robot detection events are blocking, which means that processing of an event can only happen one at at time, and blocking movement in your detection event handler will keep you from accepting more events. This forces you to keep all the heavy processing and movement in the main execution loop, while using the event handlers for setting flags, and storing event values. The whole situation reminded me of the bottom and top half's of the interrupt handlers in operating systems. If your interrupt handler performs lengthy computations or transfers you run a risk of missing important events, such as network packets or timer ricks, since interrupt handlers run with interrupts disabled. Instead modern OS's interrupt handlers gather all the interrupt data and schedule it to be processed in the normal kernel context.

I was still able to finish my goal of 13 robots, with all the capabilities described above. This got me thinking about creating a competitive robot. I have a pretty nifty idea for target prediction which involves a Fourier transform of the accumulated competitors positions. If the robot is moving in oscillatory motion Fourier transform will give me a fundamental frequency of the movement, which in turn will allow my robot to calculate the future position of the enemy. The number of positions transformed can be tuned by the hit/miss factor. If the enemy robot is very chaotic the algorithm will eventually fall back to only using three points which is equivalent to a basic projection. On the other hand if the opponents movement are very periodic the algorithm should perform much better then basic projection, hopefully with hit rate of some of the more advanced pattern matching algorithms. Watch out SpinBot here I come.

So here are my adventures in Robocode. Till next time.

JUnit in java

2011-08-30T11:03:00.001-10:00

JUnit is a testing framework for Java programs. Here are my JUnit adventures with the FuzzBuzz program:

package edu.hawaii.ics613;



public class FuzzBuzz

{

	/**

	 * @param num: Number to be processed

	 * @return: string according to the FuzzBuzz rules.  

	 */

	public static String proccess_number(Integer num)

	{

		if(num % 15 == 0) return "FuzzBuzz";

		if(num % 3 == 0) return "Fuzz";

		if(num % 5 == 0) return "Buzz";

		return num.toString();

	}

	

	/**

	 * @param args: Ignored  

	 */

	public static void main(String[] args) 

	{

		for(int i = 1; i<= 100; i++)

		{

			System.out.println(proccess_number(i));

		}

	}

}

Here is the Junit class:

import static org.junit.Assert.*;



import org.junit.Test;



import edu.hawaii.ics613.FuzzBuzz;



public class FuzzBuzzTest {



	@Test

	public void test() 

	{

		///Test for trivial case

		assertEquals("1", FuzzBuzz.proccess_number(1));

		///Test for %3 case

		assertEquals("Fuzz", FuzzBuzz.proccess_number(3));

		///Test for %5 case

		assertEquals("Buzz", FuzzBuzz.proccess_number(5));

		///Test for %15 case

		assertEquals("FuzzBuzz", FuzzBuzz.proccess_number(15));

	}

}

It took about 10 minutes to get a hang of JUnit, thanks to the autocompletion in Eclipse. Remember [CTRL + Space] is your best friend. So I guess that's enterprise software engineering 10% code, 45% documentation, and 45% testing. So that's is JUnit. Till next time.

Google Sites Page

2011-08-28T16:58:00.002-10:00

I made a Google sites portfolio page. If you are interested in my work check it out here.

The Three Pillars.

2011-08-28T16:28:00.002-10:00

My software engineering class has recently introduced a concept of the three prime directives of software engineering, applied to an open source project. The directives are as follows:

Does software accomplish at least one useful task?
Can a new user successfully install and use the software?
Can a new developer successfully understand and enhance the system?

I decided to put this knowledge to the test, by applying these questions to an open source project JwordPad.

Here are my results:

The software is a clone of the WordPad editor, which comes installed with M$ Windows operating system. The UI is written is swing, so it does not integrate well with the OS. It does not use the default font, instead it picks the first available font from the OS at startup. Apart from that the software is a usable replacement for Wordpad, as long as you have 50Mb of system memory to spare on an editor with no syntax highlighting.
Installation is straight forward, software is redistributed as an archive comprised of both binaries and source. A simple command of java JWordPad will bring up the editor. I was able to open and save text files; however the editor stalls on any file larger that 1Gb, even though it was running on a 6 core Phenom with 8 Gigs of ram.
All together the program is a bit shy of 600 lines of code. Most of the code lacks comments, however code is well formatted and readable. Given a rudimentary knowledge of Java and swing, any developer can jump in and improve the program or add new features.

So these are the prime directives. Till next time.

Minix in VirtualBox

2011-08-25T14:47:00.002-10:00

My operating systems class is focusing on Minix this semester. This means all students are required to have access to a Minix system in order to work on the class assignments. I did not have a spare computer to run Minix, and it seems silly to run a ~~barely~~ stable research operating system on a production laptop or workstation. So the only way out was virtualization. I am a fan of Oracle's VirtulBox, so I decided to stick with it.

First attempt at installation was disappointing. As soon as the OS got past the CD boot loader, I got a kernel panic. It seems that in order to boot Minix in VirtualBox, the host CPU must have the special virtualization instructions, as described here.

Once I moved to a newer machine OS booted and installed in under 10 minutes. With 10Gig virtual drive and 64MB of ram the os feels snappy and responsive. Pkgin package manager is somewhat similar to apt, however the amount of available software is pitiful compared to any modern operating system. Some of the packages are simply broken, sudo utility core dumped every time I tried to run it, cscope printed garbage to the screen, but such is life...

I did manage to install the openssh server and forwarded the ssh port to the host machine. This allowed both shell and filesystem access to the Minix system, so I can use non-Minix IDEs and version control tools from the host machine without having to worry about getting the code onto the Minix file system.

Here is a screenshot of Minix VM with an ssh session connected to it.

Posting code in blogger

2011-08-24T22:12:00.003-10:00

Here is a blog post describing how to setup code highlighting in blogger. Here are my results:
Java:

//FuzzBuzz code for a java program

package ics.test;



public class test {



	public static int main(String[] args) {

		for(int i = 0; i< 100; i++)

		{

			if(i%15 == 0)

			{

				System.out.println("FuzzBuzz");

			}

			else if(i%5 == 0)

			{

				System.out.println("Fuzz");

			}

			else if(i%3 == 0)

			{

				System.out.println("Buzz");

			}

			else

				System.out.println(i);

		}

		return 0;

	}



}

x86 assembly:

;FuzzBuzz program in x86 assembly with nasm

;To compile use:

;nasm -f elf -l fuzzbuzz.lst fuzzbuzz.asm

;gcc fuzzbuzz.o -o fuzzbuzz -m32

extern printf 

SECTION .data 



fuzz:		db	"Fuzz", 10, 0 

buzz:		db	"Buzz", 10, 0 

fuzz_buzz:	db	"FuzzBuzz", 10, 0

num:	db	"%d", 10, 0 



SECTION .text 

	global main 

main:

	mov eax, 1

loop:

	push eax

	mov edx,0

	mov ecx,15

	idiv ecx

	mov eax, edx

	cmp eax,0

	je fuzz_buzz_case

	pop eax



	push eax

	mov edx,0

	mov ecx,3

	idiv ecx

	mov eax, edx

	cmp eax,0

	je fuzz_case

	pop eax



	push eax

	mov edx,0

	mov ecx,5

	idiv ecx

	mov eax, edx

	cmp eax,0

	je buzz_case

	pop eax

	push eax

num_case:

	call num_print

	jmp loop_itt_complete

fuzz_buzz_case:

	call fuzz_buzz_print

	jmp loop_itt_complete

buzz_case:

	call buzz_print

	jmp loop_itt_complete

fuzz_case:

	call fuzz_print

	jmp loop_itt_complete

loop_itt_complete:

	

	pop eax 

	inc eax 

	cmp eax, 100

	jle loop 	

	ret 



fuzz_print:

	push dword fuzz 

	call printf

	add esp, 4

	ret

buzz_print:

	push dword buzz 

	call printf

	add esp, 4

	ret

num_print:

	push eax

	push dword num

	call printf

	add esp, 8

	ret

fuzz_buzz_print:

	push dword fuzz_buzz

	call printf

	add esp, 4

	ret

Suspend your disbelief

2011-08-24T14:29:00.001-10:00

As the digital age moves forward, prospective employers are turning to the web in order to closer examine their applicants. Unfortunately as far as academia is concerned the professional persona is not the number of blogs you maintain, or the number of linked-in recommendations, but the number of publications under your belt, and the amount of funding you have available for next year.