Monday 1st October 2007
With one thing and another (like summer holidays), there has not been too much progress made over the last two months. However, I haven't been totally idle, but have designed a new motor controller circuit that hopefully has a few advantages over my previous version in Hog 2 that was prone to blowing up the power MOSFETs.
This version is based on three PIC micro-controllers that will handle the control of the left and right motors as well as the flipper pneumatics. The main objectives of the new motor controller were:
After a fair bit of research during the summer, I came with a circuit that I then tried to squeeze onto the smallest piece of strip board as I could. The picture below is the result of a few evenings soldering in the garage.
Saturday 13th October 2007
With the circuit board built, it was now time to start programing the PICs. One of the PICs was going to be responsible for analysing the signals from the radio receiver and passing this information onto the other two PICs which were each responsible for driving the wheel motors. I could have used the Microchip IDE environment to program the PICs in machine code, but I wanted to make life a little easier so decided to look for a suitable (and affordable) C compiler. I came across the Sourceboost PIC compiler at www.sourceboost.com which seemed to be quite good, and also came with a Real Time Operating System (RTOS) as part of the compiler.
I started programming the radio receiving PIC, but with a first version under test, I had two problems. The first was that I couldn't seem to detect the start and stop of the radio channel pulses, even though I could see them on an oscilloscope connected directly on the PIC pins. It took a little while to figure out what might be going on, but I came to the conclusion that the outputs of the radio receiver must be open collector.
I added a few pull-up resistors to the PIC input circuits which seemed to do the trick. However, the second problem came about because I was using the RTOS option on the compiler. I needed to accurately measure the width of the radio receiver pulses, but with the various processes taking place within the RTOS all the time, there was quite a variation in the measurements I was reading. The cooperative multi-process features of RTOS is all very well, but it relies on each task "yielding" to the other tasks at regular intervals. However, there may be a delay before one task yields, and this was the problem. I reluctantly had to stop using the RTOS options and go for prioritising the tasks in hand.
I re-wrote a section of the program that would do nothing but wait until it detected a transition on the receiver input, after which it would take a snapshot of the time. With this stored, I could then do some calculations before returning to monitoring the input signals again. This seemed to reduce the jitter I was experiencing.
Last updated 26th October 2007