Contents

History

Acroname maintains a large volume of code for product applications, software API's, website interaction, and contract work.  Started in 1994, this pool of software has seen it's share of evolution.  Portions have been in Java, Perl, C, and C++.  We have also targeted a number of no-longer existent platforms and practices.  For example, when we started the code-base, there was no commercially available browser, Windows 95 hadn't been released, and typical disk drives were around 20 Mbytes. 

Things have changed and our code has evolved all along.  About 2 years ago, we identified a number of redundant pieces of code and practices that we wanted to consolidate both to increase production as well as eliminate as many places where errors could go unnoticed.  To this end, we started a completely new source control repository and a shadow set of new libraries, applications, and website tools...  all sharing a common code base in C/C++. 

This work is now done and we are at least caught up and in many regards well past where we were with the former tree.  It is time to move to the new tree and let the other, legacy tree go. 

Set the Bar

We code cross-platform and things evolve over time.  Our users are almost all early-adopters or at least near the leading edge of new releases, technologies, and hardware.  We standardized on one code-base, one set of compilers, on set of platforms, and we make every effort to keep these consistent...  moving them forward at exactly the same pace.  Analysis of our customer base shows a nearly even split between Windows, Mac OS X, and Linux users.  We don't embrace the notion of incidental platforms. 

Currently, we target:

• Mac OS X 10.5 and higher
• Windows XP and higher
• Linux 2.6 Kernel and higher

The compilers we use are (thankfully, as of this writing) all free for each platform.  Discussion compilers, IDE's and development tools is a fast-track to a faith based argument.  Getting this right for everybody is just slightly easier than establishing lasting Global peace. 

Recognizing that, we have standardized on minimal build environments that each platform avails the public at no charge.  We aren't trying to support a given platform or technology for some OS vendor.  We are just trying to get our work done and keep access for people on our platforms consistent. 

Our goal is to have a simple base OS machine with a free and zero configuration tool installed build our work.  We want you productive and studying the logic of our code.  Our code is written in, and our example projects are maintained in:

• MacOS X using XCode
• Windows using MSDEV Studio Express
• Linux using command-line gcc/g++

We try to minimize any reliance on a "flavor of the day" like the latest API from Microsoft, the cool new Window manager on Linux, or a strange non-standard language on the Mac.  Where we can, we stick to nearly ANSI C and we roll our own framework for UI where needed. 

This approach helps us document and maintain a consistent metaphor for our software tree regardless of where it is running.  Some things like our configuration files may seem antiquated in a point-and-click world for users but when you start moving that same code to an automated server or embedded application like robotics, they are insanely helpful. 

What Changes in the Migration?

The external view of changes is minimal.  The required OS versions are different but not out-of-line with staying current.  We now have the same support on all platforms with built executables for each. 

The software is no longer organized by application but rather by product.  If you have a product that requires a software download, we try to include everything you will need for that product.  This is often multiple former downloads in may cases to keep things simpler. 

Command line tools are now available for common BrainStem functions and the Console is a command line tool as well, rather than a UI application.  Very simple, very flexible, and super easy to use when logged in to a headless processor running on a robot scurrying around the floor. 

We have a new login area with greatly expanding functionality.  Keep an eye on this as we intend to put far more tools at your disposal to help your projects sing.  First in this is the addition of blabs.  Blabs are a collaboration and publication tool to help organize, maintain, and document your work whether individual, classroom, or production teams.  Externalized change requests are now available allowing you to request a feature, check on a problem, report a bug, and optionally be notified when things are resolved. 

Much better consistency and usability across applications.  We now have common object-oriented underpinnings for most of our applications so we can leverage changes and improvements across all applications.  We also have spent the past 15 years supporting customers like you and we have tried to incorporate better messages, warnings, and resolution for the most common problems we see. 

Expanded tools.  We have a great deal of software we use internally to perform tasks as disparate as loading ARM firmware to scheduling a cross-country race for an employee's daughter on Saturday.  We are trying to share these tools more where we can to better accomplish our goal of easier robotics. 

Thanks

We can't say this enough.  Our customers input, questions, success and problems all contribute directly to how we move forward.  We write this code for you, so thanks for the help.  Keep in the loop by starting a blab, adding change requests when you see a general need, and by all means...  use the software. 

Revision History:

• 2009-10-28: Our revised software distributions are available in downloads