The ultimate servos would now be the TGY-605BL, Goteck HB1621S. Less torque but fast.
These servos might be fast enough for jumping robots. Unfortunately, they may have been discontinued because of overheating. There are no brushless, high speed servos in production. The next level in speed are the TGY-615BL & Goteck HB1623S
The 1 month shipping time & risk were too high & led to a cheaper brushed servo 1 week away.
Before then, the Futaba was run at higher voltage, which yielded no difference. Frequency domane feedback has been the biggest win. Removing the servo saver traded erratic swerves for oscillation.
Doing it all for the mane.
Testing with the servo saver removed from the Futaba S3003 was better & worse. It didn't have any of the erratic swerves, but couldn't go without oscillating. It needed triple the P, half the D & 1% lower bandwidth to get close.
The best results ever achieved were with the generic Tower Hobbies TS-53. They didn't last long, even with the servo saver. All of them are now broken & they're not likely manufactured, anymore. They were good for pointing cameras but not vehicles. The specs between the cheapo & the Futaba actually show the cheapo a hair faster.
The problem is the independent suspension had to go to lower the CG. Past vehicles like this had a hard time steering. Any bump sent them off. Skid steering might help on flat surfaces.
Burned 3749mAH or 428mAh/mile, so that was unchanged. Roll resistance remanes very low. The problem might be in the transmission.
It was acceptable without a payload, at 6min/mile & 9 min/mile. It burned 4359mAh for a very high 416mAh/mile. After pushrod adjustment & algorithm improvement, it's still far less range than it used to be, so perhaps the slight toe out that resulted from not having enough pushrod to center the wheels killed it. The right wheel pushrod is too short.
Oscillations happened randomly, seemingly from rough terrain. The thought occurred of using a quaternion for determining heading, to compensate for rolling. It didn't jump out as a killer solution because it wasn't a killer solution in quad copter days.
Another tweeking of FIR bandwidth & rate feedback without FIR didn't work. The bandwidth of 0.9 came from bode plots & the vehicle's natural frequency.
The next step now is replacing the servo saver with the methuselah of servos.
The mighty $43 Turnigy™ TGY-615BL standard size, metal gears, brushless. Steering burned up brushed motors too fast to justify the cost of any high end servo. Metal gears were unavailable in any standard size servo. Early brushless servos appeared years ago for over $100, only in giant size & only with plastic gears. Turnigy now has a complete line of brushless servos at dramatically lower prices. It might obliterate all the investment in algorithms for any reason other than imitating Lars.
Today's winner was 150P 0.1I 1000D. Tried FIR bandwidth from 0.85 - 0.95, but still only got useful results at 0.9. Would say it doesn't react enough at 0.85 & reacts too far into the natural frequency at 0.95. Tried smaller constants for FIR filtered angular rate feedback, but it was still worthless. Leaning towards the steering being too slow to compensate for angular rate.
The testing protocol has been driving in a straight line up & down the parking lot, looking for oscillations. Then, driving in a straight line while holding the slow turn button or tapping the fast turn button to induce oscillations. The camera mast has simulated a payload.
A new camera mast is needed for the gopro. Not sure whether to build a whole new mast, a new head, or just mount the gopro at ground level as before. The difference between ground level & mast so far has been having a video or nothing.
The 1st drive without any camera mast was rock solid when not given steering inputs. It didn't search or anything, just going straight. So testing with the unstable payload is effective at predicting it without a payload.
When given steering inputs, it was still erratic before settling again. It was only useful on the rail trail, but any turns were quite difficult. There's still changing the bandwidth of the FIR filter. What would Lars Blackmore do in this situation?
You can tweek PID constants forever, chasing changing payloads, weather conditions, & speeds. At least, they converged on values that would wear the tires out acceptably & go reasonably straight. It's not going to be perfect. The highpass filtered angular rate was worthless. It's amazing how for you can go with just highpass filtered heading. The next step would be adjustable bandwidth.
Note how the FIR filter isn't an exact phase shift of the error. Just fishy how it needs to be 7x the P gain.
Attached the sphere cam to simulate the worst case oscillation. It's beyond what any commercial heading hold vehicle has to contend with. The traditional method is adding ballast & using a large enough vehicle to keep it from oscillating. Doing it with software will never make it as stable as the traditional method, but buys portability.
The lowpass P + highpass D filter was a total failure. It simultaneously oscillated while being too delayed in tracking the heading. The allpass P + highpass D filter was promising, but more erratic. D needed a 1000x gain & P needed a 200x gain, which made the lion kingdom wonder if P was doing anything at all, but D had no DC offset without P.
Suspect another term which highpasses the angular rate would improve it.
For determining gain & bandwidth constants, there's the bode plot.
If the traditional damping method involves a highpass filter, a notch filter at the resonant frequency should be even better.
When applied to the test data, it nicely leads in the high frequencies but lags in the low frequencies.
So back to just high passing.
Test data shows some ability to vary the amount of leading by varying the D gain & filter stages.
A single wavelength gives some idea of what's leading. The more filter stages, the more the highpass leads the input, but it doesn't do anything dramatically different than the unfiltered feedback.
Shifted the pushrods so the wheels were centered when the servo horn was centered. This was off, but wasn't causing the oscillation. Because the servo is off center, lowering the suspension made the right wheel extend more & made the steering naturally pull right.
Pushrod alignment can't be corrected in software, because of the geometry of the servo horn. The pushrods still weren't long enough to handle the lowered suspension, so they're still pointing slightly to the right. A slight toe out is required with the lowered suspension. Tire wear is caused by oscillations.
The vehicle requires a diaper to collect oil from the gearbox. The gearbox is real noisy without massive soaking & it's hard on the ears after 20 miles.
In other news, you can make a notch filter of sorts with the PID controller's resonant frequency. The problem is the 4 independent variables: gain & bandwidth for the high & lowpass.
A student lion could derive FIR filters directly from laplace notation of AC circuits. Nowadays, all lions can do is look it up on kiwipedia. Using actual driving data recorded on the Odroid, the highpass filter was a more delayed & smoother version of the D feedback. The highpass filter needs the D scaler & a bandwidth from 0-1.
The highpass filter is:
y = bandwidth * (prev_y + input[i] - input[i - 1])
prev_y = y
The D in the original PD feedback fights all the frequencies of the input.
output = P * input[i] + D * (input[i] - input[i - 1])
If the (input[i] - input[i - 1]) is replaced by the highpass filter, the D now fights only high frequencies of the input.
output = P * input[i] + D * y
You get a sharper cutoff by stacking multiple highpass filters.
y = bandwidth * (prev_y + input[i] - input[i - 1])
y2 = bandwidth * (prev_y2 + y - prev_y)
prev_y = y
prev_y2 = y2
FIR filter2 varies much more greatly by bandwidth & gets farther ahead than the single order filter.
Kiwipedia has a complicated formula for calculating bandwidth, so lions just graph it until it looks good. It has to be 0.9 to 1.