At Neya, we have set up a build server using Jenkins (http://jenkins-ci.org/).  Easily installable through apt on a Linux box or a basic download/install process, Jenkins has straightforward setup instructions.  The base platform will allow you to automate builds running on the machine it was installed on.  I recommend creating a simple hello world project using your company standard build system (cmake, ros, visual studio, etc) and using that as a setup to test the build server.  Preferably something that compiles relatively quickly.  Using an existing project with a multiple-minute compile time will greatly increase your down time while doing the basic setup.

Using the basic setup with just a build script doesn’t seem at first glance to be all that particularly useful.  You’d have to have a separate build machine for every platform type, and you have to go to your build server page and click to start a build, or put it on a simple automated schedule.  That doesn’t really get you what you want.  Fortunately, Jenkins also allows plug-in development, and while you can always make a plug-in for your particular build system, there are already quite a few plug-ins developed for the more common ones.   For instance, if you use cmake, there is a plug-in for cmake builds that correctly automates the cmake/make process for you.  If you use subversion or git, there are plug-ins to link your projects to those servers.  You can then set up your projects to automatically build any time someone does a check-in.  Don’t want to go to the build server page to check your build status?  Well, there is a plug-in that will allow you to set up email lists for whenever the build status changes.

Finally, and most importantly, there are plug-ins to integrate the build server to various types of virtual machine systems, including both virtualbox and vmware.  Setting these up allows your build server to compile the software for multiple platforms simultaneously.  I’ve found this to be one of the most useful tolls available on a build server (beyond automated testing, which I will hit on in my next blog).  Writing software that can run on multiple architectures is not that hard, but maintaining it through months of development and different developers is.  A simple automated process that tells a developer that they broke the windows build with a change they made that worked on their Linux system can save hours and hours of headaches with developers and even customers later on down the road.

While sometimes it may seem to be superfluous and time consuming to set up, I can attest that setting up and managing  a basic build management system is not only easy to do, but saves way more time in the long run that it takes to set up.  You will have a project that is being developed for deployment to multiple different architectures.  The first time someone makes a change they think works because it compiled on their machine and the build server blasts out an email saying it failed on the other 3 architectures is a thing of beauty.  You will have not only saved time, but you may have not found out that bug for weeks.  Whenever someone forgets to add a new file to the repository, you find out immediately, instead of a month later when you give a new employee repository access and they try to do an install.  Have a bug fix on something you sent out 3 months ago that your customer finally got around to testing?  Well, now you can have the build server automatically tee a new release up on command, instead of having to make sure you’ve still got that setup correctly for a project you haven’t compiled in months.  It is clearly worth the day or two of initial setup and day or two a month of maintenance required.  Now, making sure the engineers who have deadlines  use it for their projects is another story entirely!

Motivation
Why does a roboticist need embedded systems? These days mobile chips are becoming powerful enough to run a variety of algorithms, from control to sensor analysis to communication. Some mobile boards are beginning to offer dedicated GPUs with support for GPGPU languages (CUDA and OpenCL). The advantages of these full systems is their light weight, decent power, and tiny power requirements. For our hands on, we will focus on SECO’s new Carma DevKit. This board has a quad core Tegra 3 along with a Quadro dedicated gpu. There are tons of other well supportedrry Pi’s and TI’s OMAP boards. 

Standard Embedded System
Many roboticists have installed an OS (ubuntu, mint) and found it to be easy. With embedded systems, things are little more complicated in that you must compile a a kernel image for your specific system. That kernel image must be loaded by a boot loader with correct kernel arguments, which differs from our standard BIOS based PC boot loaders. Finally, we need to load the drivers(modules) we compiled against our kernel image. I am still learning this process myself, but lucky for us tons of documentation and tools exist on this subject. However, sometimes it helps to have a general overview of what we’re working with and how it works. So we’ll examine the basic steps behind setup.

The standard boot loader for embedded systems is U-Boot. This boot loader is small enough to fit on most boards memory, advanced enough to be compiled with basic drivers for our system and offers a configuration console. When booting, U-Boot allows a user to interrupt the boot process and configure the boot parameters. Boot parameters control a variety of settings for the system itself. We can set video memory for cards with gpu chips, enable or disable specific drivers, the device and memory location of our kernel image,  and/or the device and memory location of our root file system. Once the kernel image is loaded, the boot loader will attempt to load a root filesystem. There’s a few approaches to this, the most common I’ve seen are NFS (Network Filesystem) and SD card based.  With a NFS approach, tftp is used to transfer necessary files from a host computer to the board which is booting. This may include the kernel image itself! With an SD card, typically we use “dd” to specifically write the U-Boot binary in the correct memory locations (usually described in your systems manual), add the kernel image using dd, set its location in U-Boot and go from there. An indepth example of these approaches can be found on U-Boot‘s webpage. An even more indepth tutorial on U-Boot and embedded system setup can be found at this website.

Cross-Compiling Background
The basis of cross compiling is compiling for a TARGET machine on a HOST machine. Typically the TARGET machine will differ in platform than the HOST (for example, compiling for ARM on an x86). The HOST machine usually installs a prebuilt binary cross-compiler (you can also build it yourself). If installed through a package manager, the package manager will install some basic cross compiler libraries for you as well. You will also sometimes get cross-compilers with Board Support Packages.The combination of a cross compiler, linker, and associated libraries is called our toolchain. Many build environments will take advantage of toolchains to cross compile for you. For example autoconf and cmake will both cross compile for you.

Autoconf is tricky, in that the flags you use have been revamped to do what you want. You would use the –target option. However carefully examine the output of the script, it will tell you if it found your cross-compile toolchain. (It looks for [type]-gcc NOT [type]-gcc-4.5, so set up your softlinks!) CMake makes it extremely easy, you simply specify a toolchain file. A more indepth explanation can be found here as well as in CMake’s documentation.

The major difficulty with cross compilation is dealing with symbols and libraries. Our HOST compiler uses the typical ld search paths (/lib, /usr/lib, /usr/local/lib), but our cross-compiler needs cross-compiled libraries and symbols. When cross compiling, the difficulty really lies in cross linking, using the correct libraries for your TARGET. There are tons of tiny assumptions that can create errors which make no sense to someone entering the cross compiling world! We’re going to go over a few debugging techniques here as well as some important flags.

Cross Compiling Headaches
The most important thing in cross linking is to know what libraries are being used; to examine the search paths of your compiler you can use the -print-search-dirs:

arm-linux-gnueabi-gcc -print-search-dirs

Second, use linking flags to correctly specify linking behavior. You should already be aware of the -L flag’s use in specifying new search directories, but more importantly you should be aware of the -Wl flag. This flag allows you to pass flags to your linker, this is useful when you’re using a compiler that also calls the linker for you on the object files. There are tons of linker flags, but there are only two main ones you needs to know -rpath and -rpath-link. These two flags help specify the runtime path of your binary object, in other words where it should look for dynamic libraries it needs to load. The -rpath flag will help remove “undefined symbol” messages at runtime when you’ve obviously linked the library.

But wait, if I’m compiling a binary that runs on another system I can’t set the -rpath to the location of my toolchain, it won’t be right on the TARGET system! That’s correct, which is why -rpath-link exists. This flag allows us to tell the linker that we only wish to use this runtime path while linking and resolving dependencies, but use the standard runtime paths. For example, our libcudart.so is in /home/constantin/workspace/linux_tool_chain/lib on our HOST machine but in the standard /usr/local/lib on our TARGET machine. So our compile line would be:

arm-linux-gnueabi-g++ -o test_cuda test_functions.cpp 
  -L/home/constantin/workspace/linux_tool_chain/lib -lcudart

or, if we are linking a dynamic library cross compiled for our cross-compiled libcudart.so

arm-linux-gnueabi-g++ -o test_cuda test_functions.cpp 
  -L/home/constantin/workspace/linux_tool_chain/lib 
  -Wl,-rpath-link,/home/constantin/workspace/cross_compiled_opencv/lib 
  -lcudart -lopencv_core -lopencv_gpu

In order to link in our libopencv_gpu.so, which has symbols from libcudart.so, we need to tell it what library has the CUDA symbols and the runtime path of the library but ONLY at link time.

There are a few interesting libraries that you need to watch out for: libpthread.so and libc.so. These are no normal shared objects, they’re scripts (do a less on /lib/libc.so)! So when you get Board Support Packages and you link directly to the TARGET filesystem’s directory, you might end up with errors. This often occurs when you have an NFS filesystem and you link directly to the root filesystem which exists on the same harddrive as your cross compile environment. The scripts execute and they instead link with your HOST’s system libraries. A great explanation on this topic can be found at this Stack Overflow question.

Hopefully that’s enough to get you started or help you deal with some very obscure bugs! Next time, we’ll focus directly on the CARMA Seco Board, as well as how to compile using CMake.

This week, I’d like to talk about something non-technical, that is very near and dear to me. The Carnegie Mellon Reasonable Person Principle (RPP). The RPP is a set of very basic rules that were originally developed to govern usage of CMU’s computing network, and are as follows (taken from http://www.irc.perl.org/reasonable_person.html):

1. Everyone will be reasonable.
2. Everyone expects everyone else to be reasonable.
3. No one is special.
4. Do not be offended if someone suggests you are not being reasonable.

These four very simple rules apply to all areas of life, including business, and is one of the most valuable lessons I learned in my time at CMU. We try very hard to run Neya by these rules, in how we deal with each other, our customers, and our competitors. Here’s what this means to me.

The easiest case in applying RPP is in dealing with each other within the company. We treat each other with respect. We work as a team. We don’t allow company politics. We try to be as transparent about projects and business operations as possible. This is the normal stuff that all small businesses tend to be good at – especially ones that follow the “no jerk rule” (also known by a different name, but this is a family friendly blog…)

We also apply RPP to our customers. We go in and work to make sure that we and our customers are on the same page and the same team. We assume that they are not out to “get” us. In return, when a customer does ask for something that may go above and beyond, we accomodate it. We’ll go the extra mile to handle customer requests. This actually works really well and builds mutual trust. It’s another thing that small businesses can do that larger organizations may have trouble emulating at times.

The hardest one is applying RPP to competitors. However, I think it’s the most important, especially in a relatively small industry like the robotics community. While we push hard to win projects and proposals, we try hard to do so by promoting our strengths rather than other’s weaknesses. One of the great things about our industry is that sometimes we work on the same team with folks we may compete against in other efforts. That means it’s important to maintain bridges and cordial relationships. In addition, there is fluidity in the robotics job market, just like in any industry. Someone who may have worked for a competing company one day, may be your customer at a new organization. Reputation matters. Being an honest broker matters. Treating people well, and with respect, matters.

So we treat our competitors reasonably. We don’t bad-mouth them to customers. We look for ways to work with them when we can find complimentary strengths. We most especially do not take any joy in their misfortunes. Robotics is a small community, of usually like-minded individuals who have a deep interest in developing innovative technology to help alleviate the dull, dirty, and dangerous work that others do on our behalf. Especially for those of us in DoD Robotics, we are *all* working for not only the taxpayer, but more importantly, our soldiers in the field. I’d rather spend my time fighting our adversaries, than fighting competitors, who, at their core, tend to be very much like us.

The above isn’t meant to be an earth shattering revelation. It’s just a reminder that ultimately we are all on the same side. We need to pay attention to our businesses, and ensure their growth, and develop useful technology. However, it’s in everyone’s interest if we can do it reasonably.

That doesn’t mean, however, that JAUS is useless in these situations.  In this article, I’ll focus on two ways we can maintain run-time interoperability even if existing, published services don’t cover your exact need.

The most obvious approach is to use the HMI Service Set.  This is a set of published JAUS services which effectively enable a “remote desktop”-like environment.  Rather than the display/OCU pulling information from the vehicle/sensor like it does in most JAUS implementations, the HMI Service Set allows a vehicle/sensor to push data directly to the display.  There are JAUS services running on both the display side as well as the vehicle/sensor side to negotiate mouse and button clicks, some simple widgets, and other common display tools.  Since the display becomes basically a dummy terminal, it’s assumed that a human operator is available to interpret and act on the data being sent.

The second approach to interoperability in the face of specialized requirements is through service inheritance.  SAE JAUS introduced inheritance that follows a model very similar to class inheritance in object-oriented programming languages like C++ and JAVA.  By inheriting from a parent service, a child service agrees to implement, and potentially extend, the interface offered by the parent.  There are some very specific rules about what a child service can do, but basically: Adding behavior is okay, changing parent behavior is not allowed.  When these rules are followed, a child service perfectly mimics the interface of the parent.  At run-time, a client service can’t tell if it’s talking to the parent or the child service.

We can make use of service inheritance to add functionality and behavior that’s close to a published service while still maintaining some level of interoperability.  Let’s consider an example in which we want to add arrival time to a waypoint.  Published JAUS services allow for specification of waypoints (Global or Local Pose Driver), but timing is controlled purely by setting a travel speed.  In our case, we want to explicitly define the time of day for the vehicle to arrive at the waypoint, and let the vehicle plan the best way to achieve those goals.  We therefore define the “Arrival Time Waypoint Driver” which inherits from Global Waypoint Driver.  Furthermore, we’ll define our own custom message that includes both the position of the waypoint as well as the arrival time.  Since all services are unique, we’ll also need to give our new service a unique urn, like urn:jaus:dave:blog:ArrivalTimeWaypointDriver.

Figure 1. Example Service Inheritance Chain

So how does our new service achieve interoperability?  By exploiting the inheritance relationship!  Since the child interface must adhere that of the parent, our new service can register with the discovery service as *both* a Global Waypoint Driver and an Arrival Time Waypoint Driver.  For clients that only speak pure JAUS, they can still talk to our implementation using the standard published waypoint messages and travel speeds.  Sure, they aren’t taking advantage of the full functionality of the service, but at least we’re getting some interoperability.  For clients that are aware of our custom Arrival Time Waypoint Driver interface and the new message we created, they can use the arrival time message to take advantage of the new functionality.

Of course, the best way to achieve interoperability is to get new services published.  I strongly encourage folks to get engaged with the Committee.  If something is lacking, bring it to our attention.  Give us your interfaces (not your implementations!) and we’ll do our best to incorporate into the published sets.

Thanks for reading!

I am a self-proposed outsider to the robotics industry. I am an accountant and have worked in various areas of the financial world, including the auditing and advisory services group for a large CPA firm, the accounting department of a Fortune 500 company, and have managed numerous financial consulting engagements. I was in the depths of the Sarbanes-Oxley craze and learned about the significant importance of sound internal controls and compliance. This was my career “pre-kids.” Once I became a mom, I was looking for a job that would allow for a flexible schedule and a lower stress level. That’s how I became the part-time administrative assistant and bookkeeper at Neya Systems.

While I consider myself to be an educated professional (I have a B.S. in accounting and a CPA license), I am amazed each and every time I walk through Neya’s doors and am surrounded by conversations that I am unable to comprehend in the slightest. Robotics engineering phrases abound, and I smile to myself before I even reach my desk. I think, “Wow…I am surrounded by smart people…I mean really, really intelligent folks.” And while all of the employees here have the degrees, experience and innate intelligence to back it up, it is so refreshing to be greeted with cheerful hellos and genuine smiles. These guys love what they do, and they sincerely enjoy for Neya, a small company where all ideas are considered, brainstorming occurs on a daily, if not hourly, basis and management is truly invested in ensuring the success of both the company and the employees. This is a place where everyone learns from each other, helps each other, relies on each other and laughs with each other. I find the sense of humor here to be hysterical and often hear and engage in bellowing laughs as we all joke with each other and discuss a range of topics (including my one C++ class that I took in college at which everyone loves to poke fun!)

I am only in the office one day per week. I take on various tasks ranging from ordering supplies and putting together lunch meetings to maintaining a sound DCAA-compliant accounting system and providing accurate project costing forecast models and indirect rates tracking spreadsheets (stay tuned for a future blog on the extreme importance of these!) While these robotics engineers work on writing detailed code for unmanned systems and various technologies, I have to keep them on track administratively and ensure that they correctly complete timesheets and expense reports and maintain all receipts for project purchases. While our interactions may seem mundane in the exciting world of robotics, I have come to form sincere friendships with these people. And in comparison to other jobs I have held, I have never met more sincerely appreciative people who consistently tell me “thank you” for even the smallest offer of help (new supplies and office treats go a long way with these guys!)

These days, I really do get a good laugh every time I work at Neya’s offices–mostly due to the tidbits of comic relief offered by these robotics geniuses throughout the day, but also partly because of my own realization into the irony of how much I truly enjoy the opportunity to experience a small part of the robotics world.

Some caveats are in order, of course. There are a number of researchers who have used machine learning to improve their iris recognition results or tackle related problems such as iris image quality: Arun Ross at WVU, Tienjui Tan and colleagues at Beijing and Elham Tabassi at NIST spring to mind. But the temptation to just find the perfect feature for what you are trying to do is overwhelming for a number of reasons. First, the application is nicely constrained: controlled lighting, a static target, the distance to the target known, etc. Second, the structure of the eye is fairly uniform. Irises and pupils are circular… well sort of. The eyelid shape doesn’t vary too much… more or less, probably more. And so on. It is a matching problem in the end, so why not just devise a way to create a unique code for each iris? But the final, most important reason is the dramatic success of the initial algorithms that gave birth to the field, algorithms that had little to do with machine learning. Where else in computer vision do you see an idea taken to market so quickly and work so well? There are iris recognition systems fielded all over the world making millions of identifications with few false recognitions or rejects. And they all stem from the work of John Daugman, and, in fact, mostly employ his algorithms.

The base Daugman algorithm is ingenious for its simplicity. Detect the outlines of the iris and pupil; transform the extracted iris using a polar-to-Cartesian transformation; apply a bank of Gabor filters to extract phase information; encode this phase information in a bit pattern; match bit patterns. There are lots of little things to do along the way and clever ways of doing them, but that is the crux of it. So where is the need for machine learning here given the success of this method and its variants? That brings us back to what made this domain so attractive: the constraints and a priori knowledge. If we now want to loosen those constraints and deal with the outliers that defy our a priori assumptions, we have to become more flexible. And that is where machine learning comes in. Thus the slow drift in the iris recognition community toward machine learning as customers express the desire to recognize irises at a distance in less than ideal lighting conditions with the target moving. It is extremely hard to devise an algorithm to handle all the possible variations. This is in part due to the fact that it is extremely hard to imagine all the possible variations. So being of limited imagination, we simply go out and collect many examples of these new conditions. We could then comb through the data and try to figure out the correct rule for handling each particular case and hope that we had covered them all. Or… we could let a machine learning algorithm discover the best way to weight each feature and save ourselves this tedium and likely failure.

One reason that many don’t take the plunge is that there is an upfront cost to machine learning: the accumulation of a representative set of labeled examples. There is also a looming unknown: how many and how widely must we sample to get a representative set? The rule-based approach also has these costs attached to it, but it is on the back-end. Using a handful of examples, you devise your rule. Then you try it on some more, modify it accordingly, and continue trying it on further examples. Rinse and repeat. You still have to make the decision as to when you have evaluated it on enough examples, and to do that, you still have to label data. You just don’t have to do that before you can apply your algorithm, so the cost goes unnoticed initially. We have been through this cycle in the field in the early days of robotics and it has convinced us that it isn’t worth it. And the results are poorer.

Another reason to take the plunge is that, well, not everyone is as smart as Daugman. His algorithm took insight and ingenuity. Its simplicity convinces us that we all could have seen it. Perhaps given enough time and thought this is true. Perhaps. But we don’t have unlimited time to devise the perfect algorithm. So it makes sense to sink the time into the tedious collecting and labeling of examples. There still is room for creativity: machine learning isn’t a panacea for bad features. You still need to figure out how best to represent and reduce your data. The domain expert is not banished from the scene. But there is no reason to believe that he can know the best weighting of the features he has extracted. The combinatorics of the domain prohibit this.

The tedium of labeling is slowly being alleviated by services such as Mechanical Turk. Or rather, shifted to others who are willing to do it for little money. What is needed are better tools for doing the labeling, tools that make the labelers more productive. We have some ideas along this line that we are developing and will hopefully become a product. But until then, it still makes sense to invest the time into collecting and labeling, because you will do it in the end regardless of the approach you take.

So when is machine learning appropriate for robot vision, our main area of interest? I would argue that unless your application is more constrained than iris recognition, it always makes sense.

In this particular case we had an application where we needed to compute a quick lowest-cost path from start to goal, given a small terrain costmap, for a customer application where use of company-proprietary algorithms would have caused headaches. No problem – ROS provides an A* and a Dijkstra path search algorithms as part of their “NavFn” package. We grab the package, integrate, and move on.

Later when testing we find odd behavior when computing minimum-cost paths on some types of noisy cost maps. Every once and a while, calcNavFnDijkstra is unable to find a path when a valid path clearly exists. Since Djikstra is not a complex algorithm it is not high on our initial list of suspects, and, it takes us a little while to determine that the error isn’t in our code (by providing a badly-formed costmap, for example). Finally we take the time to read through the ROS file navfn.cpp. (In this case we’re using the ROS fuerte distribution — comments on the latest Groovy distribution are below).

The problem turns out to be, not in the underlying cost calculation (which appears to work just fine), but rather in the “calcPath” routine which extracts a path from the Djikstra-labeled potential matrix. At a high level, the navfn calcPath works as follows:

Begin at start location

While (cycle-limit not exceeded)

If (at goal)

return success

If (any of the cells surrounding the current position have infinite potential)

take a step in the 8-connected space towards the lowest potential.

Else

Compute a numerical approximation to the potential gradient

If (gradient is 0)

return failure

Take a half-cell step along the maximum-gradient-descent direction

Endif

Endwhile

The goal of the routine is clear: to follow the gradient in potential from the start to the goal, resulting in nice, smooth paths rather than the 8-connected zigzags which will result from simply jumping from each cell to the lowest-cost neighbor. There are problems, here, though, and they’re tied to the gradient approximation. Not the specific method — there are many ways to estimate gradient from a discrete grid of samples, and the one used is as good as any. The issues are that:

1. The approximated gradient could be 0 even when one or more of the surrounding cells has lower potential. In that case, the routine will fail unnecessarily.

2. Taking a finite-sized step along a numerically-approximated gradient will generally take the system to a lower potential when the costmaps are nice and smooth, but there’s no guarantee: it can easily move to an equal or higher potential, particularly if at or near a saddle point in the potential – this can lead to all kinds of problems (such as infinite cycling).

What was causing the problem for us was case (2) —  the system got into a state where taking a step along the numerically-estimated gradient took the system to a higher potential instead. It then went into a loop, jumping between two potentials, and eventually failed.

The rewrite was simple: for case (1), check to make sure there isn’t an 8-connected step which will reduce the potential before returning 0, and for case (2) check for the case when moving along the approximate gradient actually moves to a higher potential and handle it appropriately.

That solved our problem, and we were able to move on.We were actually about to post the fix to ROS when we checked the latest Groovy distribution from February 2013, which has made some improvements to the original routine: 1 and 2-length cycles in case (2) are now trapped and handled.  It’s unclear whether cycles of longer length can occur, so we’re sticking with our fix for now, which will catch cycles of all lengths; will actually remove the cycles, rather than leaving them in the resulting path; and handles and the 0 gradient case as well. There’s no downside to the extra checks, since path extraction is quick anyway.

This experience is characteristic of some of the underappreciated dangers of re-using code from other programs or groups. Bugs will always occur, of course, in your own code, those of other team engineers, and in software provided by others in your company or the community — but bugs from outside-program and outside-company software can be particularly challenging, because they must be found in software where you have

1. limited access to the code author to ask questions,

2. limited knowledge of the conditions under which the code was written (last-second demo rush?) and

3. little knowledge of the degree and type of testing which that code has encountered.

Open-source code is a wonderful thing, and ROS has definitely help us accelerate application development. We’re grateful to all the ROS contributors, appreciate their contributions, and we’ll continue to leverage it wherever we can — and to make our own contributions as well (we’ve posted this fix to the navfn FAQ, for example).  Just make sure,  when using open source code from ROS or anywhere else,   that you’re prepared to dive in if you need to, and that the value of the piece you want to use makes up for the added debugging complexity.

Doug’s expertise in UAS Interoperability and Architectures will allow us to expand our growing expertise in this area. Neya has been a strong supporter of open architecture efforts since our founding, and we strongly believe in the technical and business merits of OAs. Doug shares a similar viewpoint, and brings to Neya decades of experience in this area, concentrating on the actual deployment of these technologies with Army and Navy customers.

At Neya, Doug will maintain his leadership role within the UCS Working Group (www.ucsarchitecture.org), and will also focus on growing Neya’s OA capabilities with an emphasis on deployment of our OA-based software capabilities.

There is no doubt that considering an employment change can be very stressful for a person. The fact is that in today’s job market it can be very easy to get comfortable in the position you are currently at. The thought of potentially moving to another city or state, knowing you will have to acclimate yourself with a new company and new projects…these are all things that can make a job change seem to be more hassle than it is worth.

About three years ago, I was in this position. I was working for a large government contractor that employs over 70,000 people across the country. Things were going very well for me at the company. I had just received a promotion, and I was excelling at the projects I was working on. Life was very good. However, I still felt like something was missing. In my case, working for a large, very mature company, meant that I would mostly be contributing to large, very mature projects. Many of the tasks that I was assigned revolved around project maintenance, bug fixes, and add-on feature implementation. There is nothing wrong with this type of work, they are all completely necessary parts of any project’s lifecycle. However, in my case, I wanted to feel like I was truly innovating, and I didn’t feel like I was getting that at my current position.

At this point, I decided to start doing some research to see what other, more fulfilling jobs, might be out there. Because of my current position, I was hesitant to look for open positions at other large companies. This led me to Neya Systems.

Parag and I had previously been introduced to one another through a mutual business contact. I knew that he was heavily involved in the robotics industry, and since I had previous robotics experience I thought I would reach out to him to see if he knew of any open positions in the field. It just so happened he was just starting to spin up Neya when I contacted him, and few short months later I was signed on to start as Neya Systems’ first employee.

So what made me take the plunge and accept a position as the first employee at a company? Here are some of the key points that helped me make a decision.

Transparency. Joining a small company can be scary, joining a company as the first employee can even be scarier. The financial viability, the reputation, and even the management of the company can all be cause for concern in a small business. From day one, I felt as though I had a clear idea of the fiscal health of the company, how it is being managed now and will be in the future. It is this kind of transparency that helped me to feel extremely comfortable joining.

Work-life balance. This is a slightly personal one. Joining Neya Systems was going to allow me to move back to my home town of Pittsburgh which was something that I really wanted to do. However, I knew that working for a very small company would require hard work that might even extend beyond normal business hours. This was something that I was completely alright with, I have never had a problem working hard, and living in your ideal city, in my case, was worth a lot to me.

Technology. I was looking for innovative work, and the robotics industry is the place to find it. After speaking with Parag, I knew that I would be able to contribute to some amazing projects. In addition, since the company and projects were young, I would be able to get in on the ground floor and help to shape the way they are developed. As a software developer, this is something I find very appealing.

The transition from working for a large company to working at Neya Systems has truly been a smooth one. While the work environment is obviously very different, the benefits of joining have greatly outweighed the risks. As the company continues to grow, it has truly been a pleasure to watch it evolve from two people in a two room office to eleven people in three different states, and I look forward to seeing what the future brings.