About this Blog

This blog is an engineering log book; for me to record the progress on my many projects and hopefully to inspire you.

Some projects do not get off the ground, they remain as interesting thoughts, a select few get some work done on them, even fewer get close to completion, and none get completed because unfortunately I subscribe to the theory: "If something ain't broke then it doesn't have enough features". If you'd like to collaborate on some work to get something to a useable state then send me some communications.

Being a blog, posts are listed in chronological order. However I usually have multiple projects on the go and will try to post some of my earlier work. With this in mind I'll try to add labels to each post so all posts relevant to one project can be easily extracted.

Enjoy and happy hacking.

Wednesday, October 15, 2008

Waving Hello World

We have servo action as can be seen in the video above. I have written some code to read the ADC, calculate a PID control and provide a PWM signal to the motor. This all comes together to move the position read by the ADC to the set-point, which is moved backwards and forwards to make the servo wave. This is all done with 8-bit integers, however the ADC gives a 10-bit result, so next task will be to make it work with 16-bit integers - giving it 4-times the accuracy.

I've had a few hiccups along the way.
The first was a problem with the piklab-prog program that loads the PIC through the ICD2 programmer. In short it was writing the contents of the last memory address 0x3FF(the oscillator calibration word) back to the memory location 0xFF, overwriting what was there. So I filed a bug report and reluctantly moved development to a windows machine.

The second is choosing a C compiler for the PIC. Hitech is a commertial compiler company that write compilers for the PIC. They seem like they should work well. They provide a free compiler PICC lite, but this doesn't do any optimisation - you have to pay for that. Buy you can use a 45 day trial of the optimisang standard version PICC std. It is also available for linux which is nice.

Third problem is one that had me bamboozled for a couple of days. I was working on the PWM H-bridge control. The left side is controlled by one GPIO1 and the right by GPIO2. The motor would spin fine in one direction but not in the other and causing the MOSFETS to heat up quickly. Having a look at the signals on an oscilloscope revealed that when GPIO1 was written high, it would go high for one instruction cycle but not stay high. This had the effect of making the mosfet switch on and off very quickly and hence the heat. After talking to Phil at uni he suggested that I was writing to the second pin too quickly (which I was - in the next instruction in fact). The problem is that the PIC operates with a read of the port, modification of the pins, and a write back. The read of the next instruction occurs just after the write of the last instruction. The write is delayed by the capcitance on the pin or other factors so the read of the port (which read the values of the pins) got the wrong value (one without the recently modified pin). This is called a RAW (Read after Write) hazard. To fix this you need to do something in between or modify both at the same time.

And finally I'll end with the question of using a sigma-delta modulated output for control? Since the PWM at best runs at only 100Hz, not giving very precise control of the motor, maybe a sigma-delta type control would be better. It would have a "variable frequency" higher than 100Hz, fast response to a change in the servo position. It would also be smoother on the powersupply with several servos on the same bus with synchronised PWM.

Monday, September 15, 2008

Time Pieces

I have a little fascination with time pieces, not your regular clocks though, but interesting ways to display the time. Every now and then I think of a new idea (or find one on the net) that I think would be cool to have sitting on my desk.

The Nixie clock. I have a bunch of nixie tubes that i scavenged from a 1960's calculator. A nixie tube is what ws used for electronic displays before the 7-segment led came along. They are neon lights with cathodes in the shape of the numbers 0-9. When you apply ~200V between the cathode and annode the neon glows an awesome orange colour around the cathode. The difficulty with this project is the high voltages required.


The Binary Clock. Simply six columns of upto 4 led's that light up with binary numbers. Simple, but you have to be a bit of a geek to read and appreciate it.

Volumetric Display Clock. A 5x5x5 cube of RGB leds. Can display alot of cool patterns on it but also the time in a number of ways.
Multi-meter clock. And my latest idea, have a microcontroller generate three voltages that extend to three test points labeled Hours, minutes and seconds. By probing with a multimeter you can discover the time.

Tuesday, September 9, 2008

Software Plan - First Run

Minimum specifications:
  • Use the existing hardware.
  • Run at 4MHz = 1MIPS on the internal RC oscillator to free up two extra pins.
  • Servo communications,
    • Bit bash a one-wire serial communications protocol,
      • based on dallas 1-wire bus?
    • Bit bash a two wire bus (maybe easier),
      • I2C.
    • Traditional servo pulse width command.
  • Each Servo individually addressable,
    • 255 unique addresses 0x00 - 0xFE,
    • one broadcast address 0xFF.
  • Servo action - position control,
    • PID controller,
      • Adjustable P, I and D gains.
    • Other controller (LQR?).
    • Dead band adjustment.
  • PWM power control for motor.
  • Debug LED(s).
  • Store configuration in EEPROM (128 bytes),
    • Address.
    • Controller gains.
    • Control limits,
      • Position extremes.
      • Torque\Current extremes.
    • Home Position.
Optional features:
  • Current sensing,
    • additional current sensing amp hardware required.
    • use additional ADC pin (GP4).
  • Constant torque controller.
Design Overview:
At startup:
  1. Load the configuration data from EEPROM data memory into RAM.
  2. Configure device.
    1. GPIO, GP1 and GP2 output (H-bridge).
    2. GPIO, GP4 and GP5 (comms).
    3. ADC, GP0 input (Pot).
    4. TIMER0 (8bit, 1MHz, prescaler 1,2,4,8,16,32,64,128,256) for PWM.
    5. TIMER1 (16bit, 1MHz, prescaler 1,2,4,8) for Comms.
  3. If startup bit START_CONTROL set then initialise control to "home position", else disable motor.
  4. Initialise communications protocol, begin listening for address.

Friday, September 5, 2008

Series Hybrid Electric Tandem Bicycle

So I'm going to take a ride on the alternative transport band wagon with this idea. My girlfriend and I try and cycle most places, unfortunately she is about half my size and I'm twice as fast as her. Solution: a tandem bicycle. Only she worries that she won't be able to contribute to the propulsion because we are so mismatched, I pedal too fast or use a different gear than she would use or something. So I thought - you need independent drive trains. And of course, being an electrical engineer I turn to electronics to solve my problem.

Why not, instead of the pedals driving a gear set, have them coupled to a low speed generator. Then from each pedal gen-set combine the power produced using a couple of power electronic converters to match the voltages onto a common DC bus. From there a third power-converter could run a heafty hub motor at the rear wheel (and the front too). A fourth converter could be used to attach a battery to the system and provide energy storage absorbed from excess human effort and regenerative braking and depleted for use uphill and takeoff.

The pedal generators could be controlled to provide a constant cadence and torque, individually adjustable to suit the cyclists. One problem is that the RPM is quite low ~ 60-100 rpm. Since the voltage generated is roughly proportional to the speed of the generator (change of flux inside the generator windings) a multi-pole machine should be used (more than the usual two to four). The torque at the generator shaft is proportional to the current.

One final benefit to a series hybrid bike. There is no dirty chain or temperamental derailer to deal with. Just simple, maintenance-free and clean electrons.

It's unlikely that i'll get around to building this. However I have spoken to my supervising lecturer and he is going to offer it as a final year engineering project next year. So I may still get to ride it.

Friday, August 29, 2008

It's Alive!


LEDs are a flashing. How exciting! Nothing gets a hardware engineer going like a couple of flashing LEDs. It symbolises success. Half the battle is won when you can program a piece of hardware to flash some LEDs. It means that you:
  1. Soldered the major components correctly,
  2. Have a working power supply,
  3. Have a tool chain for compiling programs for the hardware,
  4. Have a method for downloading the code to the hardware.
So I removed the 8MHz resonator connected to pins 2 and 3, not needed since the PIC has an internal RC oscillator. I soldered two LED resistor pairs between ground and pins 2 and 3 respectively. I then grabbed some assembly code from this site, and modified it to output to the two LEDs alternately. It is listed here:

; An LED Blinker

list p=12f675
include "p12f675.inc"
__CONFIG _CPD_OFF & _CP_OFF & _BODEN_OFF & _MCLRE_OFF &_PWRTE_OFF & _WDT_OFF & _INTRC_OSC_NOCLKOUT

small_delay_tmp equ 0x20
long_delay_tmp equ 0x21

goto main

small_delay:
movlw 0xff
movwf small_delay_tmp
small_delay_L1:
decfsz small_delay_tmp, F
goto small_delay_L1
return

; ----------------------------
; W contains count on entry.
; Store it in a temp variable.
; Keep on decrementing and
; calling small_delay
; ----------------------------

long_delay:
movwf long_delay_tmp
long_delay_L1:
call small_delay
decfsz long_delay_tmp, F
goto long_delay_L1
return

; ----------------------------
; The main LED blinker
; ----------------------------

main:

bcf STATUS, RP0
clrf GPIO
movlw 0x7
movwf CMCON ; disable comparator
bsf STATUS, RP0
movlw 0x0
movwf TRISIO ; All pins outputs
bcf STATUS, RP0

infinite:
bcf GPIO, GP5
bsf GPIO, GP4
movlw 0xFF
call long_delay
bsf GPIO, GP5
bcf GPIO, GP4
movlw 0xFF
call long_delay
goto infinite

end

I assembled it through piklab with gpasm from gputils. I then downloaded it through the ICD2 programmer again using piklab, configured so that the board is powered through the ICD2 (it doesn't seem to work otherwise). Amazingly the LED's flash, just like they are supposed to. Yay.

I'm not a fan of programming in assembler, so I'm going to try a couple of C compilers like SDCC. Unfortunately the PIC12F675 has only 1 kwords (1 word = 14 bits = 1 opcode) of program space, so to getting a C program to fit maybe a challenge. But why not try.

Programming Successfull!

So I spent a morning trying to get the programmer to connect to the PIC and remove the code protection.
After trying a few different default devices, the programmer (MPLAB ICD 2) successfully read the device identifier word. The PIC is a 12F675, datasheet and info. So now it knows what it is dealing with.

The remainder of the time was spent trying to get the damned programmer to erase the chip. An erasure would apparently work but a blank-check failed. So how about changing the configuration word (which has bits for code protection), can't do that either. So after much googling I found the problem, detailed here and here. In short, I think that the program already on the PIC was beginning to execute and messing with the programmer clock input. The output drivers of the ICD2 programmer arn't strong enough to over power the PIC and get it to program. So you have to get it into programming mode before it starts up and set pin 6 to an output. I achieved this by powering the PIC from the programmer (at 5V) instead of externally powered though the 3.3V regulator. Another option would be to disconnect the external oscillator, thus preventing the program from running.

So after that I managed to successfully erase the PIC. Yay! And I can reprogram the configuration byte. Note: I got a warning that the ICD2 programmer doesn't support programming with an internal oscillator and the MCLR pin set to a digital input. Probably to avoid the same situation as above.

Thursday, August 21, 2008

Some hurdles

So the PIC has no spare pins. Therefore to get a single wire serial bus to the device we must use the existing input wire and pin. The most common one wire bus is that of Dallas semiconductors and their 1-wire bus. No point reinventing the wheel (well not yet) so I plan to implement it on the PIC.

The 1-wire bus works by the master or slave device pulling the bus low for varying amounts of time to communicate 1's and 0's. No clock is required as each device is assumed to have a relatively stable clock source.

While reading the PIC datasheets I discovered a problems that will make the 1-wire bus difficult to implement. Pin-4, the one connected to the control wire has no output driver. It is an input only pin. This makes it impossible to pull the bus low.

Ok! So two options here. Put in a more modern micro-controller without these restrictions, like the Atmel ATtiny range. Unfortunately the power pins are not the same as the PIC - so messy rewiring needed.

The second is to change the pin. But there are no spare pins. Well actually the PIC has an internal RC oscillator, so the external 8MHz resonator isn't required. Yay two extra pins. One for the 1-wire bus and one for an LED too :).

Ofcourse this all depends on if I can actually reprogram the PIC.

Wednesday, August 20, 2008

Servo has a PIC, Can we connect to it?

I've identified the servo chip as a 12-series PIC microcontroller. The next question is can I connect an in-circuit programmer to it? I've borrowed a MPLAB ICD2 USB programmer from the resident PIC guru in my department. Cheers Phil. I wired it up as shown below and fired up LPLAB (MPLAB for linux).

Success! I can read the configuration fuses on the device. As suspected the code protection bits are set. The next thing to do is to try and write a progam to the device. I'm not sure if it is possible as some PICs are made with one-time programmable memory (not flash).

What's Inside the MG995 Servo?

The servo of choice (MG995) is the cheapest high torque (~15 kg/cm) servo that seems to be available world wide (at least it used to be). There is also a big brother servo (~20 kg/cm) that comes in Jumbo size and with nylon gears). I believe they are an OEM servo made in china like all cheap hardware. They are traded under a number of names, commonly Tower Pro.

Now lets break it open and work out what the nitty gritty bits inside are. The servos are labeled as "digi", which some take to mean digital. There are discussions on RC forums about these servos and if they are actually digital and how good they are. Apparently digital servos are better - better holding torque, less dead band and more responsive. The forum concensus was that they wern't digital (because digital servo's should be expensive). I'm not into my RC vehicles so I don't know much about servos, but I am a trained electronic engineer. As we shall soon see these servos are in fact digital (and i'd suggest that analogue servos would be more expensive).

Inspecting the circuit board inside we find:
  • three SOIC-8 ICs (5 in the big brother) which have had their marking removed (thanks Mr Manufacturer guy),
  • a couple of electrolytic capacitors,
  • some surface mount capacitors and resistors,
  • an 8MHz ceramic resonator,
  • a couple of transistors,
  • a 3.3V linear voltage regulator.
All but one of the SOIC-8 packages, (those next to the motor connections) are MOSFETs two N types and two P types in a full H Bridge configuration. On the MG995 board the two chips appear to be something like an IRF7309, housing a pair on N an P type MOSFETs, making a half bridge each.

The transistors provide the inverted full supply voltage drive signals to the P-type MOSFETs.

The final component of question is the 'contol' IC. In an attempt to protect the design the top of the IC has been scraped to remove the markings. I suspect the IC is a microcontroller.

The micro's pins are connected to:
Pin 1. VCC
Pin 2. Oscillator
Pin 3. Oscillator
Pin 4. H-bridge control
Pin 5. Servo's PWM control input wire
Pin 6. H-bridge control
Pin 7. Potentiometer input (ADC?)
Pin 8. GND

The micro is probably a PIC, since they are cheap and well known. After a bit of internet searching the pin-out matches the 8-pin microcontrollers of the 12-series PICs. The PIC12F510 being the most likely.

Truly Digital Servo Project

So I have these servos that I've used for a couple of projects. They are labeled "Tower Pro MG995". They are high torque (~15 kg/cm) servos with ball bearings and metal gears - perfect for robotics. Best of all they are cheap, I've seen them on ebay for < 10 USD, shipped from Hong Kong. They are also often re-branded by RC hobby-shops, a typical example is from rcnz.com here in Christchurch, NZ.

The control of RC servos in robotics projects is an often discussed problem, and it is fairly easy to provide the pulse width control signal from a microcontroller. There are plenty of websites discussing this. One thing that they don't tell you is that often they can be updated at more than the standard 50Hz, I have successfully run the MG995 servos at 60Hz (to match the 30 fps frame rate of a webcam).

However this PWM control is a bit of a drag. What if I want:
  • lots of servos in my system - requires lots of control signals.
  • feedback of where the servo actually is - have to add an extra wire to the internal potentiometer and read with an ADC.
  • control over the velocity profile of the servo's stroke.
The solution is to hack the internal control of the servo. Have a look at the openservo.com project where they have developed completly new electronic internals for standard servos. They seem to have done a very nice job but the 37 USD is a little steep for me. I may try and leverage some of their code though.

So what do I want?
  1. A bidirectional serial communication protocol - using a single wire, preferably on a bus system.
  2. A better control system - able to be given not only a position set-point but a velocity set-point. So looking at a state-space control system, with progammable gains to allow the control to be matched to the dynamics of the system it is connected to. Maybe even with some system identification or machine learning thrown in.
  3. Use a minimum of extra-parts. Because I am cheap and being in NZ makes anything but the simplest of parts difficut to obtain without a $50 shipping charge.