I’m not sure how you’re tuning the Pitch controller but in any case, this should be done in Manual mode and ideally using real-time display of the PID controller’s inputs and outputs (e.g. “piddesired” and “pidachieved”).
I also suspect that these parameter changes should be made to your vehicle
ATC_BAL_FF = 0 (currently 0.5). If anything I would have though this gain should be negative but I have not yet tried this on my own balance bot
ATC_BAL_IMAX = 1 (currently 10). I don’t think it helps to be larger than 1 although it may also not matter.
WRC_ENABLE = 0 (currently 1). I think you said that you weren’t using the wheel encoder controller…
Sadly my balance bot has some hardware problems but I will resolve these issues over the next few days and test some of my advice myself.
I’m continuing my investigation of BalanceBots and I’ve got some enhancements to the pitch controller which moves the ATC_BAL_SPD_FF (feedforward using speed) to ATC_BAL_PIT_FF (feedforward using vehicle’s current lean angle). In my testing this improves the pitch control and allows reducing the ATC_BAL_ gains to reduce the bobbing. Feel free to give this a try if you have time.
I’ve also found that, as you said, the WRC_ (wheel rate controller) doesn’t add any value.
Thanks, I’ll certainly try it (compilation shows it occupies 5K more than version I tried on 20221027, so it contains many changes). In the mean time, I think I have:
an acceptable v4.3 setup on one balance bot;
an acceptable v4.2 setup on the balance bot with direct drive (I think the oscillation was a steering oscillation, not a pitch oscillation (so I reduced ATC_STR_RAT_P to 0.04 and ATC_STR_RAT_I to 0.08, but that gives a slow steering)).
Question: if in your branch you are moving to μs, why still in WheelEncoder_Quadrature.cpp: irq_state.last_reading_ms = timestamp * 1e-3f;?
Txs. This branch is just looking at the control, not the estimation. I think it’s sometimes best not to mix two changes together because it adds confusion as to which change is causing the improvement.
By the way, if you are seeing wobbles in Manual mode and WRC is disabled then the wheel encoder change should not be related.
I always use Acro (or Auto), since in Manual I find that balance bots turn too fast only with a small movement of the radio steering stick (or wheel in pistol radios). How can I control steering rate?
I think tuning the pitch controller in Manual mode is better than Acro because Acro mode has an additional speed controller that run on top of the pitch controller. This will make it harder to input quick changes to the desired pitch angle.
I’ve created a PR that adds add a MANUAL_STR_EXPO which I hope will help resolve the issue with using manual mode. Maybe you could give it a try to see if it helps? If it doesn’t then we can add a MANUAL_STR_SCALE (or similar) param to linearly reduce the manual steering response.
compiled and flashed. Code size was only 56 bytes more than before.
I don’t see any parameter named MANUAL_STR_EXPO to adjust. From Parameters.cpp/.h above it seems to me some declarations, but no code, although I don’t know the code, and I am not too familiar with git.
Steer handling in Manual continues more difficult than in Acro, but I didn’t try Manual before too much.
What am I missing? (May be I didn’t download the correct branch)
Should I find MANUAL_STR_EXPO in MP → CONFIG → Full Parameter Tree?
Here are two ArduCopter balance bot v4.3beta4 with manual steering expo tests, a good and a bad one, each consisting in an indoors mission, followed by turns in Acro and Manual (MANUAL_STR_EXPO=0.9).
Certainly I would appreciate it, to try other controls on the problematic balance bot (or may be I don’t know how to tune it better), and also considering that I am going to try stepper motors (also on a Pixhawk1).
Thanks for testing the manual-expo change. I think you’d find that Rover-4.3.0-beta4 performs exactly the same for the two vehicles and I think this means that the balance bot code is just as good as 4.2. Please tell me if you disagree. This question is important for me because we don’t want to release a new version that is worse than the older version.
Here is a Pixhawk1 Rover binary with the pitch limit protection. You will see that ATC_BAL_SPD_FF has been renamed to ATC_BAL_PIT_FF and I think it should be set to 0.4. For my vehicle this new feed-forward allowed me to greatly reduce the vehicle’s wobble.
You’ll also see that there are two new parameters ATC_BAL_LIM_THR (defaults to 0.6) and ATC_BAL_LIM_TC (defaults to 0.5) which control the desired pitch limiting. If ATC_BAL_LIM_THR is 0.6 this means that the desired pitch angle will be reduced back towards zero if the throttle ever climbs above 60%. The ATC_BAL_LIM_TC controls how quickly the pitch protection is invoked (lower numbers invoke it more quickly). I suspect you can leave these parameters at their default.
Re the wobble on the low KV brushless motor vehicle, I think using this new firmware may help but in any case, I think the ATC_BAL_D gain (currently 0.4) is too high. When tuning the pitch control you’re doing this in Manual mode with real-time display of the PID outputs?
Update: here is the pitch-feedforward and pitch protection in action
v4.2: I assume it has the μs/ms bug in the IRQ handler (unexplainable to me how it could work however). No pitch oscillations and silent. However, I couldn’t tune in v4.2 the direct drive balance bot (low KV brushless sensored motors), although I didn’t try too much.
v4.3: I assume the μs/ms bug in the IRQ handler was corrected (although it can be completely changed to μs and optimized in time execution). Tuning more difficult, missions followed better than in v4.2 (at least indoors), but pitch oscillations (and noise) observed in curves and clearly on the direct drive balance bot. Tuning seems to require large ATC_BAL_D.
v4.4: as tested on the direct drive balance bot, tuning possible with ATC_BAL_D values as in v4.2 and much less noise and pitch oscillation, so very promising, but falls unexpectedly (see video and log below).
I flashed Rover-440-pitchlim-14Nov2022.apj on the direct drive balance bot. Certainly, the wobble on this low KV brushless motor vehicle has improved a lot, and pitch curves seem to have no oscillations:
This is the log of it (BTW, ATC_STR_RAT_FF lowered) and this is the video with piddesired and pidachieved and the hud in MP.
So observe that piddesired and pidachieved traces move in Acro and not in Manual, but trying Acro a second time, piddesired (blue trace) doesn’t move and it falls immediately.
I don’t think I can test this indoors in a reduced space. Before trying on an outside track (such as here) I would like to have a version not falling easily.
I also wondered how 4.2 could have worked with the us/ms bug so I investigated and found that it is because we have a check that uses the system time if the wheel encoder time is too large. Because “us” was being interpreted as “ms” the numbers were huge so it was always using the system time.
I actually do not understand why the tuning changed between 4.2 and 4.3. I did try a little to test the difference between 4.2 and 4.3 on my balancebot and it drove badly on both versions. It drives well with 4.4 though so perhaps we will just backport the 4.4 changes to 4.3 instead of trying to understand further.
Re 4.4 I can’t see the video (it’s marked as private). There is quite a lot of overshoot in the pitch control. Tuning remotely is always a bit difficult but I think ATC_BAL_D is still too high.
The pitch protection should work in all modes. it is possible to make it more conservative by reducing ATC_BAL_LIM_THR from 0.6 to 0.5 (or even a little lower).
By the way, the change was merged to master (aka “latest”) so within 12hrs you’ll be able to just load latest from MP if you like (press Ctrl-Q on the Install Firmware screen).
The tracking looks quite good in the video except for the end of course. By the way, I’ve updated the pitch tuning instructions to include an explanation about how to get faster PID output displayed using the “message interval” feature.
Observe the low noise (upper microphone for catching it better) and the fast spins in Manual.
But now I cannot do missions for what I think is a hardware problem on the left wheel which has been there for ever: it gets blocked frequently (seems to disappear with fast throttle input forwards or backwards), and I have pending to distinguish if it is the motor or its controller (perhaps heard here). I haven’t found any parameter influencing this (seems sensors sync). It only happens on the left wheel, and seems to appear specially if the vehicle is moreless quiet (so it was less frequent before with more pitch vibrations). So in the meanwhile I will start with the stepper motors version.
Question: why ATT DesYaw always appears 0 when examining logs?
ATT.DesYaw is always zero because we don’t actually use an absolute yaw target even in Auto mode. The highest level yaw control is just turn rate (or lateral acceleration which can be converted to turn rate using the vehicle’s forward-back speed).
For testing a balance bot with stepper motors, I had available two Pololu TIC T500’s and two HK42BYG250-001 stepper motors (with encoders). I had tried unsuccesfully in the past, but I didn’t dedicate much time.
They are not the classical direct/quadrature encoder signals. This seems to consider only direct/quadrature encoder signals.
Programming the TIC T500’s for an RC pulse (bidirectional: <1500µs backwards, 1500µs neutral and >1500µs forwards) and using a servo tester (moved around 1500µs), therefore not requiring direction information from the FC (RELAY_PIN/RELAY_PIN2), I could get this oscilloscope capture:
Pending to complete this balance bot setup (it can go incredibly slow with 1/8 stepping, and torque seems high), obviously I don’t know how to get WENC signals as with other balance bots.
Is any trick possible to admit speed/direction (Honeywell) instead of direct/quadrature encoder signals, or will this be supported in the future (new as WENC_TYPE=2 (Honeywell))?