Programming the microcontroller is done in the low level programming language ASSEMBLY. This is a very basic language, which is quite close to machine code, but still relatively understandable for the programmer. A set of 35 mnemonic instructions is available to write the program code for the PIC16876A microcontroller.

We've done our best to increase the readability of the code by adding extensive comments and explanation for blocks of code in the assembly file. We therefore won't discuss the code further now.

This was the first time we made use of the programming language 'Assembly'. After an initiation in this language provided during the courses of  'Mechatronics', and with the help of intensive study, plenty of literature and PIC-µC documentation we were able to develop some satisfying familiarity and skills  with the Assembler language, where it had been totally unknown and very abstract to us prior to this project.

Writing an entire program in one time (especially for beginners, as was the case for us) can sometimes be difficult, but the most problems will probably surface when the testing of the program has to be done. And in that case, debugging can take quite some time.

Therefore we developed the code in parts, and tested it in this way on a test-board with leds to have a view on the signals that occur on the microcontroller pins.

We also made an integral simple program for our firetruck-robot, which doesn't rely on permanent sensing during the whole traject. This was a simple way of checking the sequential functioning of the instructions and actions to be taken listed in the program code.

Here, some experimental constant parameters (like the turning time, driving a certain way in a certain time, etc.) are being employed on some points of the parcours. The advantage with this way of working is that not many signals have to be processed and the sequence in the code to be followed is practically determined from in the beginning. (This is, because our traject is in principle perfectly known on advance.)However, one has to keep in mind that this method can only be satisfying if everything goes 'as planned'! A little misstep can mean the 'losing' of the robot. This method isn't robust!

But it's an easy way to follow the program execution on a test-board, with leds replacing the actual components that should process the signals. And as we mentioned before, 'if everything goes right' it should do the job.

Off course, we can't count on the assumption that everything will run perfectly 'as planned' for a system as complex as ours, and risk losing control over the mission. And since the sensors are available and employed anyway, it would be a pity not to efficiently make use of them and design a robot with a robust program.

Therefore, we developed a final version, which makes intensive use of the sensors during all parts of the traject and thus makes the robot smarter and robuster. A disadvantage to this method is the extremely often use of the time consuming A/D-convertor, which is necessary to process the sensor signals.

A manual mode of the robot, in which the firetruck can be controlled by way of an established bluetooth connection from a PC to the bluetooth module embedded in our PCB is also included. Here the microcontroller waits for an interrupt from a peripheral device (here the bluetooth module). Selecting the wanted mode is done by turning a switch on or off.

Flowchart (common part: manual mode + event handler):

The program code for the robot can be downloaded here; we put down the both versions, which work on different principles:

* Normal version: nor_ver (bw_total)

Principle: Start -> Check nearest side ( the entire parcours to follow is known from know on ) -> When obstacle reached, turn to nearest side untill sidewall -> When sidewall reached, turn in passage -> When passage ends, turn to white strip -> When white strip reached, follow it till flame is detected -> Start fan untill candle isn't on fire anymore.

Flowchart:

* Extensively sensing version: sen_ver (bw_sentotal)

Principle: On any time, keep in a certain distance range from a side surface (correct if necessary), and move till obstacles are detected in front; Turn untill parallel with the detected front wall; The rest, e.g. as for the tracking is the same as in the 'normal version'.

Flowchart: