Power consumption has increased to the point craft are no longer usable--fuel cells cannot keep up with battery drain
I built several rovers when the DLC came out, including this frog:
It worked fine until the newest update. Whereas previously it had reasonable range, now it can make about three jumps before completely draining the batteries. The two large fuel cells are completely incapable of keeping up with the power consumption. Other posters on the KSP forum have confirmed this issue.
Note: Action group 1 toggles fuel cells. 2 toggles play.
You will notice the same problem with this one: https://kerbalx.com/Klapaucius/Kant-Unreasonable-Rover
(note this is also in the bug tracker for an exploding problem on first load and requires reverting the flight: https://bugs.kerbalspaceprogram.com/issues/22994)
This had excellent range and now lasts about 30 seconds before losing power. It used to go 15+ minutes before needing to stop and let the fuel cells catch up.
- Status changed from New to Confirmed
- % Done changed from 0 to 10
EC consumption with robotic parts has been changed trying to improve balance, but your example crafts show how it wasn't enough.
Indeed there's a serious issue with the EC consumption with robotic parts. When the frog starts jumping, the net balance of EC = 129.95 (constant). When not jumping but the fuel cells are active, the EC balance is = - 30.17 (constant). Meaning all those parts with legs consume 129.95 + 30.17 = 160.12 EC/s. With a maximum EC stored = 2005, it takes 15.4 seconds to totally deplete EC, even with the fuel cells on.
The issue is those robotic parts keep consuming at full power even when don't produce any work. In the jump cycle, work is produced only when the legs are extending and pushing against ground to make the frog move. This happens for a fraction of the cycle, the first 0.5 seconds in how you had it set in KAL. During retraction, legs move in air so the only work done is against drag (and friction inherent to those robotic parts). It requires a lot less torque to retract legs in air (perhaps 5% of the maximum), and no torque at all for those 2.2 seconds while legs don't move; but torque currently with robotic parts is the same in the whole cycle. Less torque means less power required, so the total EC consumed for each jump would be a lot lower if torque changed during a cycle.
Now, if anybody wants detail, how much is the energy from each jump? The largest part goes with the work produced to move the frog up. Frog mass = 11.256 tons, jumps about 3 meters high against gravity at 9.81 m/s^2, so the work produced for just jumping high = 11.256 * 9.81 * 3 = 331.26 KJoules. In KSP 1 EC ~= 4500 Joules, so the above is = 73.61 EC. Note some more energy is spent to retract legs and provide the forward movement, let's estimate total consumption with each jump at 90 EC. Fuel cells produce 30.17 EC/s above whatever consumed while the frog doesn't move, so would be enough to keep the frog moving at a frequency of 1 jump every 3 seconds.
#2 Updated by email@example.com 3 months ago
Each hip extensor on that frog is set for maximum 1000 kN-m torque, and rotates π each jump, so 3.14 kJ from each hip for each jump.
KSP uses different conversions for EC in different applications. According to the right-click menus, hinges and servos give 116kJ/EC (mechanical output / electrical input) and rotors give 600kJ/EC. That is comparable to what rover wheels give us, ~1000kJ/EC.
(Sizes of batteries and solar panels do suggest ~4.5 kJ/EC; but I can see why KSP is wise to cheat the numbers so that solar powered rovers move quickly enough for a computer game.)
I can see in the right-click menu how the EC consumption jumps between max-Torque × max-Rotation-rate when the motor is moving, and zero when not moving. The bursts of energy from the frog expose how this can overestimate the EC usage. People using propellers notice they can save energy by turning down max-Torque and max-RPM to only what they really need, which might become un-fun if it encourages too much micromanaging.
Maybe KSP could charge us EC by noting actual-Torque × actual-Rotation-rate, or something in that direction. Perhaps instead of a rate, EC/second, it is possible to deduct the EC given the energy delivered: max-Torque × difference-in-Rotation-since-last-checked.