Hello, I’m using quite a few LSS HT servos, and I noticed that as soon as they’re plugged in, they seem to draw ~50mA when limp. Is there a way to reduce the idle power consumption further? I’d really like to only draw 1-10mA until I start querying and moving the servos, since 50mA @ 12V is 0.6W of idle power draw. I assume that they use an LDO to power their internal uC, but 50mA seems like a lot for a uC when the BLDC algorithm isn’t running.
1 Like
Interesting question. There are currently no commands to reduce the current draw moreso than you already are aware:
- Limp (no current draw from the motor)
- RGB LED OFF
- Updated to latest firmware
The firmware does not put the chip into standby mode, and as you mentioned there are losses due to voltage regulation. Peripherals are also powered. Current draw when idle was not really taken into account given the current draw under load can easily be over 1A. For a mobile robot, the motors rotating and holding in place would be by far the biggest drain on the battery, and for robots connected to the mains (like arms), the current draw is relatively low. Can you elaborate as to your needs to help us better understand?
Note that the internal motor is not BLDC, it’s brushed (coreless).
1 Like
Sure, I’d be happy to describe what I’m doing/what I need. I’m building a mobile robot which is autonomous and also autonomously charges itself. It has lipo 3S/12V 500mAh of battery capacity per LSS. The control board uses around 10mA of current when idle, which would allow the robot to be unmoving & not charging for 50 hrs, but the LSS makes that more like 8-10 hrs. Generally, this would be fine, the issue is that you must not overdischarge lipo batteries. This robot has the power system integrated deep inside of it, so disconnecting the power isn’t practical. As a result, if the robot were to fail to dock & this wasn’t noticed (e.g. over a weekend), this could cause a bad situation with the batteries (they have protectors, of course, but it’s still not good to drain the batteries that far).
If the power draw could be reduced, this would make the robot safer & be better for the batteries in non-optimal situations.
That makes perfect sense. Since this is the first time we’re aware of such a need, not sure how high it can be placed in terms of development, but appreciate the insights.
I’d be happy to contribute code (I do embedded ARM development) under an NDA if that could help accelerate it. I haven’t opened any of the servos to see what ICs there are, but I’d guess there’s a linear regulator, uC, motor driver, and an instrumentation amplifier. If any of these have enable pins connected to the uC’s GPIO, I’d be happy to write a bit of code for a command to turn them off. If instead the power consumption’s coming solely from the uC (totally believable, as I’ve seen that on designs I’ve made), I’d also be happy to look into implementing low-power sleep for the arm core or peripherals that wakes on an interrupt from the serial unit, so that it would be backwards compatible and just reduce idle power.
It’s funny, because I am in a similar boat for other PCBs I’ve designed for this robot–a linear regulator is drawing more power than I expected, and I’ve had to design little castellated bodge boards to access the EN pins on some components I thought would only draw a few uA of current.
The MCU used is an STMF0 and if you have a bit of code developed in STM Studio, one of our firmware developers can certainly take a look at where it might be integrated.
As for accessing the firmware, even under NDA, it’s quite closed at the moment, but the more you participate in testing, the more trust is built up. Sent you a DM here.