PBV4 output current-reading measurements

11 views
Skip to first unread message

Jeremy Morse

unread,
Dec 14, 2014, 6:24:37 PM12/14/14
to srobo...@googlegroups.com
Hi,

Firstly, all my data is here [0].

The new power board's output drivers have a current sense facility, the
aim of which is to allow a software current limit that protects the
output driver. Being able to identify an over-drawn output during
debugging is a nice feature too. AFAIK there's no intention for the
current limit to be reset-able: it's for protection and debugging.

The output driver doesn't produce a calibrated current measurement, so
we only have the ADC samples to go by. Thus, we have to do our own
calibration to work out how the ADC samples correspond to actual
current, so that we know where the current limit should be set in terms
of the raw ADC values. I've made some measurements to resolve this,
explained below.

To load outputs I've got five 50W lamps tied together for the
high-current outputs, three of them for the low current outputs. At 12V
these draw approximately 20A and 12A respectively. I've connected these
to a motor board, and to generate data ramp the output from 0% to 100%
in single percentage point increments. I take measurements with 2
sensors: the on-board current sense ic that the power board has, and the
ADC readings from the output drivers. I don't have any independent
hardware for sensing more than 10A of current, and assume the power
board hardware is sufficient.

The readings were produced with the drive_output.py script at [0], I
cooked the code in brain/sr-robot.git to work on my laptop and added
code to read the current ADC samples over USB (already implemented in
the firmware, but not software). The ADC samples read over USB are pre
scaled by 7.5 [1]. The outputs, as csv, are in the .txt files at [0].

I've also plotted the actual current readings against the ADC readings
in the png files in [0] too. The first thing to note is that the ADC
readings are pretty dirty; but not by a huge amount. (They appear to be
on the same scale as the current measurements because of the scaling
done by the firmware).

The important thing to take from this is that (surprisingly) the actual
current and ADC readings correlate linearly (despite me previously
reporting that they wouldn't). As a result we can just keep the scaling
factor mentioned above, and encode a current limit in milliamps.

Feedback on this approach would be appreciated. Without objection I'll
bake in a 10A / 20A current limit for low / high current outputs.
There'll be an IIR smoothing these to allow for transients.

[0] https://jmorse.net/~jmorse/sr/output_readings/
[1] I only noticed this after looking at the plots and being confused
that the ADC readings were already the correct scale. It turns out in
some sleep deprived state I introduced this scaling and then completely
forgot about it, only discovered this when writing this email.

--
Thanks,
Jeremy

signature.asc

Jeremy Morse

unread,
Dec 16, 2014, 4:54:40 PM12/16/14
to srobo...@googlegroups.com
Hi,

One piece of feedback delivered out of band by Rob is that as the motor
board PWMs it's output, the draw from the power board output drivers
will also oscillate, as the load is connected/disconnected. This would
make the readings I've taken inaccurate, as some of them would be during
off periods or transitions between on/off.

To observe what's going on Rob suggested attaching a probe to the actual
current sense sample point. On the power boards these are TP44 and TP46
[0]. I put a probe on TP44, connected the motor board to output H0, and
disabled the 'current_sense_poll' function in the power board firmware.
This function switches the ADC channels between sampling from different
driver ICs, when it's disabled the first ADC (and TP44) always gets
readings from U5, the driver for H0.

I did indeed find an oscillation, with a period of about 180uS. Some
screenshots when driving the motor board at speeds 15, 40, 70 and 100
(via setting the 'power' attribute through the kit software) are in [1].
The time divisions are 200uS.

As shown, these oscillations are not square waves, they're ripples on
top of a constant current. I think this is because of the ~1 milliFarad
across the 12V rail of the motor board. This is supported by the
middle-ish-power reading (40.png) having a greater peak-to-peak
difference than 15 or 70, because driving the load half-on/half-off will
lead to the highest rate of change in the charge of the caps. I think.

This probably explains the 'dirtyness' in the ADC sample readings
reported in the previous email. If you look at the graphs, for the low
current outputs the peak-to-peak magnitude is greatest at 50% motor
'speed', which matches the explanation above. It's complete chance that
they show a wave itself, rather than just noise. The graphs for the high
current outputs don't show a wave; this is probably because I used a
0.1s gap between increasing 'speed' on the low current outputs, and 1s
for the high current outputs.

IMO, the previous conclusion that the output driver's readings are
pretty much linear with the actual current drawn still holds; and the
readings are probably much cleaner than I reported.

[0] I'm very much enjoying using these test points rather than bodging
things, I used them for the i2c fixing mentioned in a previous email too.
[1] https://jmorse.net/~jmorse/sr/output_readings/raw_outputs_TP44/

--
Thanks,
Jeremy

signature.asc

Jeremy Morse

unread,
Dec 16, 2014, 4:58:58 PM12/16/14
to srobo...@googlegroups.com
Hi,

On 16/12/14 21:54, Jeremy Morse wrote:
> I did indeed find an oscillation, with a period of about 180uS. Some
> screenshots when driving the motor board at speeds 15, 40, 70 and 100
> (via setting the 'power' attribute through the kit software) are in [1].
> The time divisions are 200uS.

(I didn't take screenshots of more readings because the scope's
screenshot / save feature is relatively horrible to navigate).

--
Thanks,
Jeremy

signature.asc
Reply all
Reply to author
Forward
0 new messages