Why are we doing this?

First and foremost, to have fun. Isn't that why all open source projects exist? :-)

But there is more than that. In 2007, the Lego Mindstorms NXT world was already in effervescence. There were many tools, programs and alternative operating systems being developed for the brick, thanks to Lego's decision to make the platform as open as possible.

However, after looking at operating systems for the brick, we found a few problems that we wanted to address. Addressing those problems led to us creating NxOS and the tools around it.

Putting an end to duplication

Running an operating system on the NXT typically brings together two very different components. The first component is the base, the low-level bootup software and device drivers. That is the part that actually brings the system up and allows the second component, which we call the application kernel, to interface with the hardware. The application kernel is typically quite varied, depending on the project: for Lejos NXJ it's a Java virtual machine and a set of Java classes implementing high level interfaces. For pbLua it's a Lua virtual machine. But each of these application kernels rely on a base that is typically written in C and assembler.

Lejos was the first project to develop a working base and integrate their virtual machine with it, and soon other projets started reusing their code to get their own systems off the ground. However, they did this in the simplest, but also worst possible way, by forking the codebase and ripping out the pieces relevant to NXJ. As a result, for each NXT operating system out there, there is a base that looks very much like the other projects' bases, but has diverged organically from the original fork. It would not be surprising that some bugs that are fixed in some projects are still present in others, because they didn't "refresh the fork" recently.

There is no reason to have separate bases for each project. The real value-add of each system lies in the high level functionality and programming environment. The base is just a means to that end, and is usually considered to be that necessary annoyance that has to be cared for to keep the system runnning.

We want to build a universal base that all operating system projects can reuse to build their high level programming environments. That way, we will end the divergence of codebases that causes dilution of developer effort, and allow other projects to concentrate on the really fun part of their systems, the high level that makes them unique.

Building a comprehensive documentation

The second problem we wanted to address is one of documentation. The Lejos base code, while very effective at getting the NXT running, is quite underdocumented. The NXT sometimes requires specific tweaks and workarounds for eccentricities in the hardware. These workarounds are implemented, but not documented, leading to sometimes rather confusing code.

This is perfectly understandable: they were spearheading the effort to get an alternative to the Lego firmware booted, and had to experiment a lot to find out how to get things to cooperate properly. They were also rushed by other factors, leaving little time to document their work. Furthermore, their main interest is, understandably, the higher levels of the system. Given the choice, their time is better spent documenting and designing their Java APIs, so that people can actually use their system!

Combined with the previous point, this unfortunately means that most projects out there are now based on a poorly documented base. While their higher levels are surely very good indeed, understanding how the foundations of their kernels work is arduous at best. The real losers here are students like us, and people who want to start out in the embedded systems world. The NXT is a great platform to start out in that world, but there is no system out there that allows us to gain understanding of the structure of an embedded operating system. Certainly, you can get there with the existing codebases, but we think that it should be easier.

We want a codebase that is both maintainable and understandable, so that people wanting to start out in the embedded development world can have a clean codebase to study.

Programming on the metal

In all of the above, you may have noticed that all the systems we mentionned have a virtual machine, or some kind of high level programming environment. That is excellent, since most users of the NXT want a solid environment in which their programs can run safely. But what about the others? Sometimes, for whatever reason, you need to trade the safety of the virtual machine for the raw performance of the bare metal. Those people that want to do that may be a huge minority in comparison to the ones who are happy with the performance of a well tuned virtual machine, but shouldn't we be able to cater to the needs of the few as well as those of the many?

We want people to be able to develop programs for the brick in raw C, running directly on "the bare metal", with as little overhead as possible.

(And by the way, as a small aside: let's not get into the whole debate of whether a virtual machine can be faster than plain old C. It probably can, in some cases, by using runtime optimization based on usage patterns. I seriously doubt that you could fit an optimizing JIT compiler into what little RAM the NXT provides. And even if you could, replace the discussion on raw performance with a discussion on having as much memory as possible, and you have another problem with the same solution that we are offering.)

Where does this bring us?

Our mission is to address the above three concerns. That is, we want an operating system for the NXT that:

• Can be used as a base for higher level systems, such as a Java virtual machine, or a real-time scheduling kernel,
• Is well documented, both for users wishing to develop with it and for students wishing to learn more about embedded programming.
• Allows programming robots using plain old C, on the bare metal of the processor,

Such is our goal. Now, of course, we haven't reached that goal yet... That is assuming we can ever fully reach our destination. The path we have set down is clear, but walking it is going to take some time.

Why not head over to the features page to find out what NxOS can do for you?