I stand corrected…

I have been bashing Cyberbotics lately. I just want to note that their customer support even for non-premium customers was (unexpected) good. They fixed my problem working 24/7, and I am very thankful for that.

The problem with simulators

(This will be a university-related rant)

The problem with simulators is… well, the one with those enterprise-grade robot simulators is that they are a niche product and have all the disadvantages of those. For instance, there are no online discussions related to particular issues, since the user base is very scarce and consists of academia and enterprise.

The second problem is that the software is buggy. Always. Something will not work, in my case: the robot’s light sensors are returning bogus values. And since no discussions are available, you have to rely on the customer support that does never work in the hours when you experience failures. Which means that “Our support team will get back to you about it within a couple of business days.” is not a satisfying answer in any respect.

tl;dr: Someday, the whole Cyberbotics staff will burn in hell.

Say NO to drugs and bad IDEs!

I guess I would be more productive if I spent the time writing this post actually coding for any of the two projects I have going on, but I have to vent or I’ll just go on swearing in real life.

So, one project involves writing generic neural network code and training it on robots. The first part is actually fun (if you can wait long enough and accept that your toy functions need a lot of time to get optimized). The second part is turning into a small nightmare. Why?

  • First, the idea is that the robots are tested in a virtual environment which is run by proprietary (and the bad kind of proprietary: the one developed by small companies with strict licensing policies) software that need to be connected to the license server all the time for no reason other than authenticating your license.
  • Second, the software provides a development environment. Which sounds better than it actually is—it is just an editor with code highlighting and keyword completion. Think Kate or Notepad++. While I have been coding somewhat non-trivial database applications in PHP, like, six years ago with nothing more than an advanced editor with code highlighting, I then was not bound by any kind of deadline or any other obligation—it was a “just for fun” project—and I moved later on to better-suited tools.
  • Third, the lack of any publicly available documentation makes me code by example, which is somewhat acceptable in a small context (as I will just need to plug in the sensors into the ANN and the ANN outputs into the robot driving system), but, generally, it is just impossible, since all the cool libraries (like Qt) are not available and I am left alone with STL and Boost.
  • Fourth, and the most important part: The run/test cycles are completely inadequate for a three-week project. Training an ANN for a robot means running the simulation in real-time and praying that the ANN topology is just right and the stars stand in the positions suited for such shamanic work.

This left me with one exit: I had to code and debug the ANN code separately. Which has its own fun parts since if you have no idea what to expect from a dynamic system, you cannot tell for sure if its behavior is the intended one. But the run/test cycles are here at least less than one minute.

(The current music running in my earphones—Kill Dash Nine by Monzy—reflects my feelings towards the Webots software package as whole and the buddies that come up with such problems)

More words on software design

(If I am becoming boring, skip this post)

The awkward moment in software development happens mostly when you find out that some large part of your fancy project has been written by someone else in a better, shinier and more standardized fashion. This happened to me yesterday as I discovered that there already is a better API for generic functions than the one I have written. Oh yes, and it is called std::tr1::function (or boost::function for the poor fellas who still cannot use the goodness of Technical Report One). The good news is that I was doing it mostly right from the beginning, so the migration will not be painful. The bad news is that I still will have to migrate and document the code even more than previously, but since it is not a very large part of my project, it is completely okay.

Some words on software design

This post is rather technical, so skip it, if “overloading” primarily means severe working conditions and/or electrical circuit malfunction to you.

Two cool ideas that come from functional programming are

  • compile-time type safety
  • generic interfaces

They are very important when you try to design a library since you very often do not want incorrectly typed code to compile, which is somewhat hard to achieve since the OO world likes runtime dispatching, which may force you to impose too weak constraints on the types. Let me give an example of what I am talking about:

So what if we want to have a specialized Processor for some specialized Things? We probably will have to resort to runtime checks (in C++, you would use dynamic_cast, in Java, it would be instanceof) and throw an exception. Which is theoretically okay, but not really needed. The problem is that we mostly create the Dispatch class instance in compile-time and could control type safety without resorting to exceptions.

My idea was to replace the whole AbstractFactoryOfThings stuff with simpler specifications, like template-parameterized function objects that create Things because they are a subclass of some Factory. This way, the Dispatch class becomes Dispatch and we can safely mix and match the factory and the processor function objects without being endangered by runtime exceptions.

The whole thing comes with a price: You cannot mix the factory and the processor as a function of user input (theoretically, you can, but you have to construct all valid combinations first) anymore. Which can be annoying, but, if you design a library where Thing is something that should never be altered at runtime (like a fixed presentation), the described approach is perfectly sensible. Moreover, it generates less boilerplate code, since you do not have to come up with specific interfaces for Factory and Processor. They can be some sort of pre-defined Function<In, Out> classes.