Jon Simpson
Cockroaches & Parallel Software Design
Well, the meeting this evening was pretty interesting. Basically the e-mail reminder had said that we’d be moving on to a specific problem instead of free-form play. Given a choice of options, the group as a whole chose to pursue the challenge of modelling a cockroach’s behavioural patterns using the Mindstorms. This led into an introduction/discussion regarding both the design of models for biological items (i.e. how do we set about modelling a cockroach?) and how to design parallel programs effectively in the light of these models.
I had touched on the parallel design section of these issues earlier in the term when first picking up occam, in terms of where to start writing a parallel program. From the language I am most familiar with (Java) where to start tackling a problem is relatively obvious, you pick some objects that pertain to your overall functionality, work out how they can be modelled in terms of attributes and methods, then implement. That is, of course a gross oversimplification, and there are any number of reasons why that might be a bad approach to take for more complex projects, or simply for better overall program design. However, for beginner programmers or someone unfamiliar with the task to be achieved, it is a functional approach. Even if it doesn’t work, we can simply take Brooks’ advice and ‘throw one away’, in the process refining our design and in the process, improve the overall quality of the software.
This approach fits Object Oriented languages, but when I came in contact with occam I began to question the best way to architect parallel programs. Clearly a similar approach seems logical, to identify ‘blocks’ of the target functionality that can be implemented as discrete procedures and build them as individual elements, as objects would in an OO language. Obviously there are additional concurrency issues to be aware of in parallel languages, such as deadlocking on the channels, and making sure to architect to make good use of channels is essential, but by enlarge the approach would seem a useful one.
Brad raised a very interesting point in CSCS that destroyed a lot of my theory when discussing how to model the cockroach. He brought to the table the idea of what I will call (for want of a real term) a ‘hierarchy of procedures’ that determine the behaviour of the overall entity. The example he gave was in the three main activities it was decided a cockroach performs; light avoidance, food finding, and crawling around. These three work in a hierarchical manner when it comes to authority over the actual end behaviour exhibited by the model, as the importance of rules within the crawling around behaviour would be keeping the cockroach safe, like not wandering into a fire, or off a roof. If the food finding behaviour tries to instruct the crawling around behaviour to make such a movement, it should be able to modify the outcome such that the base requirement (i.e. safety) is still met.
I’m not sure this explanation of the idea is as clear as I would like, but basically it suggests that message alteration by multiple parallel processes through the use of an established hierarchy is an effective way to model living things in the real world. An idea that seems important when working with programs that are striving towards displaying those kinds of behaviours. I’m still considering the overall ideas behind both approaches to parallel programming, and hopefully I will be able to evolve them along the course of CSCS this year.
Enough abstract, back to the practical hands-on stuff that happened. The new build 0.3-pre of the Transterpreter bundle was out for us to play with this week, and it brought some really useful fixes. To experiment with the new environment, we rebuilt the code we’d used on the robot the week before using the environment, with interesting consequences. We initially discovered a small bug with the plug-in checking the wrong directory for the built sources, which was fixed promptly and not much of an issue. We then discovered our program was crashing the RCX block, repeatedly.
After many uploads of firmware and the Transterpreter to the block, to eliminate error on our part, the issue was isolated to the latest builds of the environment. A simpler program worked fine (and demonstrated the really cool new fast uploads allowed by the use of the first slot on the RCX for the transterpreter runtime, and the second slot for the occam byte-code), so the issue was put into bug tracking. After further digestion, it appears other people were having issues with code that referenced the bump sensors, and Christian suggested that a mismatch in OS and transterpreter builds could be the root cause. Amusingly the code seemed to work fine on a RCX simulator, but not on the genuine hardware…
Overall the session started to bring a transition between the the ‘play with lego and code a bit’ stage to ‘code to make the lego do cool things’ stage. The availability of good plans for a robot design that features most of the sensors may start to remove the building from the equation a little more, and begin to focus more on the behaviour, input/output and code involved in the process. Although that is just how I see it after the session today and not necessarily an accurate idea of where things will progress from here. All in all, a slightly more involved session than usual, but one that brought interesting ideas and challenges to bear with both the Mindstorms and occam. I await next week with continued interest…