First of all we want to thank everyone again for this wondrefull experience.
This project was a very useful, learning and joyful experience in our eyes. Solving a practical problem like this, in all its aspects and difficulties is something that will surely prove useful in one’s later career. To students electromechanical engineering, may be some kind of project like this can even be called a must.
Problems we encountered:
*****
During testing of the components on a breadboard, prior to the design of the PCB, we discovered that the H-bridge driver chip didn’t function properly. We replaced this component with a functioning one.
*****
When the PCB was prepared, the definitive program was loaded into the microchip and everything was set for the first test, we suddenly noticed some strange and unexpected behaviour on start up. The robot didn’t do what it had to do at all.
Solution:
While the program loaded in the chip on the small test boards with leds giving an idea of the logical values on the ports of the µC during execution of the program contradicted this strange behaviour, it was obvious for us that something was wrong with the newly prepared PCB.
The connections on the PCB, were the result of the establishment of a working circuit on a breadboard, the careful drawing of this circuit by hand and later the conversion to a computer printed circuit designed with the Traxmaker software. So if the PCB was a representation of what we intended it to be, there should normally be no problems with the circuitry in itself.
The first step we undertook was measuring some signals in the circuit from which the values were known. We quickly discovered that the problem was located near the µC resetting circuit. With normal use, there should have been a voltage drop across the reset pushing button, but actually there wasn’t any during all the time.
The problem was localised and solved: it was this pushing button that was placed in the wrong direction in the first place whereby it’s connection pins actually shorted out the connecting circuit instead of acting as a circuit interrupting button.
*****
After a while, after we’ve seen the robot working properly, the robot suddenly started acting weird. Has a component broke down? Is it something we changed in the Assembler code?
First of all, in our eyes, it’s a good idea of working with some kind of log book or a back up ‘last good working version’ while improving the software code.
In the earlier stages, we worked with different versions and backups (always use clear and to the point names for these different files!), while at the end, when only minor changes take place, a log book can be quite useful.
The code didn’t seem responsible for the weird behaviour. This was further underlined when we mounted the µC again on the test board with leds. Soon it was clear that an I/O port of the µC didn’t worked well, and so we replaced the mal functioning µC with a new one.
*****
Trying to communicate with the robot via Bluetooth also gave some problems. The robot didn’t react on commands. Although it was recognized and a connection, indicated through a status LED on the embedded Bluetooth module on the robot, between the PC and the robot was established.
Verifying whether the problem lied with the steering software on the PC or with the µC is a first thing to do.
Firstly, we tried sending serial data from the PC by way of a classical serial cable.
This seemed okay. We also used available commercial software instead of our own developed software to easily access the COM ports and send data through the serial cable.
But the receiving wasn’t what it should be. So we concentrated our efforts on the µC and its assembler code. At first instance, a framing error occurred. This means that the data isn’t being received as it has to be, and the incoming signals are neglected and discarded.
This could be verified because the µC sets a framing error bit when such error occurs, and an error handling is included in our assembly file.
Look up work and lots of literature then consumed quite a piece of our –on that moment- precious time, since the deadline for the project came nearer.
Then we reached a point were more or less convinced that we had taken into account ‘everything’. With our newly acquired background knowledge on the subject of sending/receiving data; With us following very carefully the steps set out in the PIC documentation pages to transmit data between the µC and peripheral devices (here the Bluetooth module, which receives signals from the PC); Maybe there’s something with the Bluetooth data transfer; Anyway, the causes can be of different origin, and we decided to –for the moment- accept the fact that no data can be sent. But ideas for solving this problem have popped up and keep popping up from time to time, so an update of this story is surely possible.
*****
On testing day, probably due to bad storage conditions, without us noticing, the line tracker sensor was a bit out of its original position. It was too close to the ground. This resulted in a bad detection of the white strip by the robot, which is quite irritating when you saw your robot tracking the line perfectly the day earlier.
So one has to be careful all the time to reduce the risk on these small problems, to notice them when they occur and to fix them.
Last Update: 21/05/2008 15:18