Skip to content
This repository has been archived by the owner on Oct 27, 2020. It is now read-only.

Enhancement request to read motor current / amps from Expansion Hub #417

Closed
JohnMMcD opened this issue Oct 19, 2017 · 5 comments
Closed

Comments

@JohnMMcD
Copy link

JohnMMcD commented Oct 19, 2017

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants