Enhancement request to read motor current / amps from Expansion Hub

[JohnMMcD]

Page 16 (a.k.a. page 18 in the .pdf) of the Rev Expansion Hub Guide says the Expansion Hub supports current monitoring:

• Current Monitoring [Not Available in Ver 3.1]
  -- Battery
  -- I2C Bus
  -- Servo Bus
  -- Digital Bus

• Per Motor Channel Current Monitoring and Control [Not Available in Ver 3.1]

Presumably the version numbers refer to the FTC SDK, so this is a known issue, but I don't see a GitHub issue for it, so here it is.

The goal is to allow teams to monitor the robot for over-stress conditions and reduce or eliminate blowing fuses.

Ideally, the current could be monitored at all the locations listed above. The first priority would be to have it monitored at the motors, since they are likely to be drawing the most current.

[ellie-idb]

This is absolutely possible by the app, but, you'd need to dig into the nitty gritty bits of the REV hub controller (including a LOT of undocumented protocol functions that are only accessable via custom headers/packets sent over i2c). The REV Hub Interface application does this, and, you're able to immediately set motor channel current alert levels (I haven't checked if this is exposed to the end-user, but, the controller can definitely do it). You're also able to directly monitor all current/voltage levels for said objects:

        self.gpioCurrent_mA = REVBytes(2)
        self.i2cCurrent_mA = REVBytes(2)
        self.servoCurrent_mA = REVBytes(2)
        self.batteryCurrent_mA = REVBytes(2)
        self.motor0current_mA = REVBytes(2)
        self.motor1current_mA = REVBytes(2)
        self.motor2current_mA = REVBytes(2)
        self.motor3current_mA = REVBytes(2)
        self.mon5v_mV = REVBytes(2)
        self.batteryVoltage_mV = REVBytes(2)

So.... I'd recommend building the implementation in yourself. I doubt it'll be coming anytime soon, sadly.
(also, question for the ftc devs, why don't you document the protocol at all??? this would be so handy if i was doing ftc...)

[WardBenjamin]

This is actually mostly implemented internally to the SDK - no need for custom headers or packets. There's an implementation available from OpenFTC as a library at: https://github.com/OpenFTC/RevExtensions

I suspect the reason that they didn't include it is because the servo current channel seems to be returning garbage data. Everything else, including LED control as well as current/voltage readings, seems to work.

[ellie-idb]

What.. no need for custom headers/packets? That’s noooo funnn :(
Very cool, though. I didn’t dig into the SDK far enough to see that. The servo current data- I’d assume that’s due to the fault of the servo driver (seeing as the chips they’re using don’t have them on-board..).

[ellie-idb]

That or the ADC something something. I can’t say for certain (since all I know is that the chip used is either based on the TI C28x core, MSP430/432, or a Hercules RM/TMS570). Not on an FTC team either, so no direct access to the hardware :(

[NoahAndrews]

This is added in version 5.4 (see README.md for details)