(Its now 4/5/17 shhhh)
Frame
So last night I was in the hackspace testing out my new hinges and moved actuator. Sadly, the hinges once again were too weak to fully support my weight (ugh) so it’s made me rethink the design of each leg. I am however going to keep the hinges for now so I can test my movement algorithms without me sitting on it. Once I know my algorithms work, I can rejig the legs and sit on it!
A couple of testing pics
Hinge failure and thread stripping argh!
Controller
I’ve done a bit more work on the controller board since my earlier post. I’ve now done a fair bit of the programming (all peripherals operating in interrupt mode and implementation of the 12 PID controllers). This includes adding the resistor network required to measure the battery voltage.
All of my tests previously were done with the microcontroller operating at 8MHz. While this was sufficient for testing, I don’t think this will be enough for the 12 PID controllers (albeit using integer math), therefore I’ve been running it at maximum rated frequency of 48MHz. This means the minimum possible SPI clock is 187.5kHz (48M/256).
Clock signal at 187.5kHz
Shift register strobe running at 5kHz
I’ve decided upon running the software PWM loop at 5kHz giving a PWM frequency of 5k/32, 156.25Hz. This seems a bit low so I’ll need to monitor the supply current during operation, it does however reduce switching losses in the MOSFETs. The beauty of software PWM is that if current ripple is an issue, I can change the phase of all the PWM outputs allowing for staggered outputs meaning the PWM relationship for each output is correct but is different with respect to different outputs.
Complementary PWM outputs at the MOSFET gates
Its worth noting that the above image was only an illustration and the motors won’t actually be driven with complementary outputs as one side of the H bridge can stay constant while the other can be PWM’d.
I’ve been looking at the CPU consumption for driving all 12 actuators. The actuator positions are sampled at the PWM frequency – 156.25Hz. To ease the ADC programming, I also sample the battery voltage and internal reference at this rate. Using this value for the PIDs is essentially equivalent to using a subsampled value compared to the PID speed. All of my PID testing was done at a sample rate equal to the PWM software loop (4kHz at the time), therefore I’ll need to retune my gain values once I’ve got the rest of the board soldered up. With the PID controllers running at the software loop frequency, the processor consumption was reasonably high unoptimized.
CPU Load (%) measured using systick, this is only an estimate as background interrupt processing isn’t included. Spikes are generally caused at the start of every PWM cycle where the ADCs are sampled. This was tested using O0 flags
The same load but with O3 optimization!
As can be seen above, adding optimization really reduces the CPU load. This is probably because it optimizes out the integral part of the controller as this isn’t used in this implementation. The bumps are still likely to be from when the ADC handler is called. For reference, O0 code consumes 6560 words and O3 code consumes 3700 words indicating more efficient code packing too. Its worth noting that there are no walking algorithms present here hence the low memory. This is the minimum code required to control all actuators in a closed loop fashion.
With hope, my 0402 resistors will arrive tomorrow along with my actuator pots so I can test the whole board out!
