The problem with simulators
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!
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
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.