Community contest linewalker line walker. mongke CONCEPT AND DESIGN The first two considerations I made were choosen from the rules , these were the fact that it need to track the line not just walk over it, And the overall speed, as it was a race with the time being taken in to consideration. I thought of using a bigger stepp then reading the line turning stepping and then rechecking the line. But because some of the turns were fairly tight it need to check the line as often as possiable.and the resulting program would have been to long, and made it slow to react. by eliminating additional phases in the program it reduced the response time to the enviromental conditions (the line) almost to the point of destroying a motor.(more later!) The light sensors need to be close to the ground with limited bouncing with this in mind I decided on a low robot that could use its body to support its self during the stepping movements, it would also need to have short legs and a rapid leg movement cycle. CONSTRUCTION and PROGRAMING To reduce weight I decided to try to build a robot with less then six legs (the last type I built) and had decided to try four. But while I was prototyping the drive unit I found I could get the required movement and speed from limited gearing and very short legs.(an extra 5mm long and it dosnt ove well at all). So the next step was to finish off the sensor array and then mount the otors and rcx better. The motors drive each leg independently from each other and rotate backwards. This lifts the foot off the ground and rotates the leg in the restraint that is near the bottom of the leg (like a piston) The first program I wrote involved three stacks the main forward movement and two sensor stacks that were tracking the line by staying on it. The sensors were mounted in the middle of the head close together and the resaluting ,5 sec movements on the corners and a high priorty on the watcher stacks caused the motors to change direction at 3-4 times a sec, i was filming it at 15 fps and it couldnt keep up! After a few runs with this program trying to sort out a few mechanical bugs, one of the otors stared aking a whirring whine that was not real nice. so i killed that program and added more blocks to stop this. The two things I did to stop this was change the motor program blocks from braking to coast (or float in NQC) and then add a small wait block to each stack to give the motors a chance to "relax" between transtions. This fixed the problem and the motor actually has stopped making the noise for now. The sensors sre hooked up to the inputs so that when the left sensor touchs the line it turns left and the right triggers it to turn right. This means it actually tracks the line by reading the brightness of the paper around it. so the sensors could now be postioned easliy as there was more room for setting them up.(double the line thickness seems to work well.) The other bug that needed to be ironed out was the fact the legs moved up from the stepping which was fixed with some more retainers on the legs. The robot dosent need to have its steps in time for several reasons. 1, its very low and self supporting 2. the coast and wait command lets the legs fall back to a nuetral postion. 3. the motors arent moving in sync so even if it gets out of sync it will fall back in to it sooner then later.( this was noted in earlier walkers that i built -hexapods). RESULTS the robot completed the course in an average of 1 min with the best run being 58 secs and the worst (3 runs) was 1 min 2sec the battries were checked at 8.3 volts (nimh rechargable) size (with wings and anntena) 28/26cm and 7-8 cm tall. the program was written in ris2 only. included files in zip: this txt.doc 3 jpgs a avi of the fastest run.(my converter keeps cutting the end off so it stops at 51 secs) and the program.