I swapped the channels for RCMAP_ pitch and throttle parameters, and this produced interesting results.
Despite SERVO_OUTPUT recording zeros at the output still, the robot wouldn’t move. Which makes sense if pitch isn’t being used, but despite it appearing to still be sending zero, it’s not reversing as before
Do you know if there is a changelog for 4.2 to 4.3? Because the fact that the reversing issue doesn’t exist when using 4.2 firmware suggests that maybe one of the parameters changed.
We found the other robot seems to be running fine with 4.3.0, but might have a different build version (it was included with the bootloader, and installed using stm32cubeprogrammer, instead of Mission Planner). The bottom is the working one.
When I compare the params there isn’t much difference, aside from additional parameters that are present in the problematic params and absent in this one (I’ll attach to this) scout1_working_no_oa.param (18.5 KB) 4_3_test_param_no_working.param (18.6 KB)
Comparing those sets of parameters turns up no obvious clues. You aren’t using GPIO, which did change significantly in the recent past, so that’s not a root cause.
Your use of LEDs on SERVO5 could potentially be problematic due to pin grouping and DMA. Disable them for now and see if that has a positive effect.
On the Matek H743 boards, SERVO13 (labeled LED on the circuit board) should be used for the NTF LEDs.
Thanks for that tip! I’m no longer seeing the reversing behaviour.
Unfortunately the controller still doesn’t seem to recognise when it’s reached the waypoint. It just keeps ‘orbiting’ the first waypoint in the mission. I can see the distance estimated to it reducing down to 0m.
I’ve rolled back to v4.2.2, and it can achieve the waypoints just fine. I’m not sure what could cause this, beyond maybe a parameter has changed somehow…
@Yuri_Rage how do I activate the s-curve behavior in 4.2.2? Scanned this thread and the param settings didn’t jump out. Is there a documentation page? I’m using 4.2.2 with wp_speed 1.2 m/s and wp_radious 0.2 meters and wp_pivot_angle of 30. Is there a way to have the autopilot use pivot turns for high-angle turns (say, >90 degrees) and s-curves for lower-angle turns? Thanks
Tested today with the latest 4.3 DEV version; 4-waypoint mission. I observed:
Rover made no attempt to round the corners - the corners looked just like pivot turns.
Rover exhibited strange behavior - when arriving at a WP it seemed to take 10-30 seconds after stopping at the waypoint before deciding it had arrived at the waypoint (as monitored by the messages window in MP). I saw it arrive at WP 1, stop, then pause for 10-30 secs, then display “Reached waypoint #1” in MP, then it commenced the pivot turn and navigated to waypoint #2. When it got to Waypoint #3, it never realized it arrived at the waypoint, instead just sitting and waiting.
Any suggestions as to how I should go about debugging would be appreciated! @rmackay9@Yuri_Rage
Go back to basics. SCurve nav is generally easier to tune than NavL1, but it very quickly points out flaws in your basic tune. Get the rate controllers behaving in ACRO. Then move on to nav again.
EDIT: Should’ve said rate/speed controllers…as evidenced by Randy’s findings below.
Txs for giving SCurves a try. It looks like the speed controller isn’t working too well. In particular the vehicle is going too fast.
The picture below is from the PIDA controller output but you can also see it is travelling too fast by looking at the THR messages. In any case, we can see the actual speed (in green) is higher than the desired speed (in red).
The solution is probably to manually adjust the CRUISE_SPEED from 0.3652 to perhaps 0.5. I see you’ve probably done the automatic cruise speed learning but perhaps it hasn’t worked well because the vehicle’s throttle curve isn’t linear. It might have worked better if the cruise speed was captured while the vehicle was at full throttle (or close to it).
Another potential solution is to increase the ATC_SPEED_P and I values from 0.2 (the defaults) to perhaps 0.4.
The good news is though that the turn rate controller tuning is looking pretty good! We see in the picture below that the actual turn rate (in green) is tracking the desired turn rate (in red) quite well.
Helpful! Back to basics indeed. Recalibrated my speed controllers, then reset ardurover cruise speed and cruise throttle, and I am seeing much better tracking on the speed controller.
But I got sidetracked by another problem which I think I need to solve first. I seem to be configured to use the wrong GPS antenna for position. When I rotate the vehicle in manual mode, I am seeing the vehicle’s position move. One antenna is directly on the center of rotation and the other antenna is 1.18 meters away. In this logfile GPS[1] remains stationary when I rotate and GPS[0] moves when I rotate.
My question is, is AHR2.Lat the output of the ekf3, i.e. is AHR2.Lat where the vehicle thinks it is? If so then I need to change my config so that AHR2 tracks with the other GPS.
I don’t think the AHR2 log file message should be used. This is for the older DCM attitude and position estimator which is not used unless there is a very serious failure in the EKF.
It is a good test to try rotating the vehicle and then confirm that it doesn’t move on the map. In the log provided I think it looks pretty OK. We can see one GPS1 (in blue) travels through a big ark while the GPS2 (in green) and the EKF’s position (in red) mostly stays put.
Here’s another test of the 4-point mission. PIDA and THR values seem to be tracking close - are they close enough? I still observe the rover approach a waypoint, slow down, stop, pause for a sec, then pivot towards the next waypoint, and resume. Note WP_RADIUS increased to 1.0m for this test. Is there some parameter I have to toggle to enable s-curves? It seems that the rover is slowed down and within 1.0 meters of the waypoint and instead of starting its scurve, the rover slows down and stops… and then pivots.
@rmackay9@Yuri_Rage can you tell me which parameters control the cross-track error? In this mission the rover makes a u-turn with two 90-degree turns. When it exits the u-turn it’s about 0.5 meter off-track. How can I get it to more aggressively get back on the line? Is it one of the PSC params?
I realize I don’t understand how s-curves work compared to the prior L1 controller (whose white paper was helpful to understand how it worked). Is there a white paper or powerpoint somewhere that describes how s-curves work?
Edit:@rmackay9 I re-read your December 2021 post and it seems I may be running into this on my mission. Further testing forthcoming…
The speed controller is doing a much better job than before but the results are a little rough. I think this could be improved a bit by reducing the ATC_SPEED_FLTE from 10 to 5 (hz).
The turn rate controller seems to be only using feed-forward because ATC_STR_RAT_P and I are zero. I think they should probably be set to perhaps 0.05 or as high as 0.1. This also leads to slightly rough steering with some oscillation. The actual (shown in green below) is slightly overshooting the desired (in red) so it might be good to slightly reduce ATC_STR_RAT_FF from 0.3 to perhaps 0.27.
We don’t have much documentation on SCurves besides the presentations and blog posts. Hopefully we will get some docs together soon after the start of 4.3 beta testing which should start within the next couple of weeks.
@rmackay9 Thank you. Do you think the EKF movement could be because my Pixhawk IMUs aren’t exactly at the center of rotation? If they’re a few cm fore or aft or left or right of the center of rotation, then would the Pixhawk perceive movement of the vehicle (and the EKF then assume movement of the vehicle) when the vehicle rotates, despite the GPS2 staying put? Do you know exactly where on the Pixhawk4 the IMUs are? (reference Mounting the Autopilot — Rover documentation)
@rmackay9@Yuri_Rage Today I went back to tuning the throttle/speed controller in a straight line with speed changes. v4.3.0-dev. I have a few questions about how to tune the speed controller. It seems the first step is to get CRUISE_SPEED and CRUISE_THROTTLE right - which I have. I understand that ATC_SPEED_FF is then set by the code based on CRUISE_SPEED and CRUISE_THROTTLE.
Is the next step then to tune ATC_SPEED P, I and D by looking at PIDA.Tar, PIDA.Act, PIDA.Err, etc?
How should I think about PSC_VEL_P, I, D and FF at this stage? Ignore them for now?
One run from today is here. with ATC_SPEED P=0.2, I=0, D=0, FF=0.25
Another question: How can I get ardurover to create a new .bin file each time I disarm and re-arm? I tried using LOG_DISARMED=1, LOG_FILE_DSRMROT=1 but I didn’t get the desired result (i.e. a new .bin logfile each time I cycled ARM/DISARM).
Throttle is most easily tuned live on the tuning graph using acro mode. If you can’t do that, then yes, check your logs for the PID values you describe.
Ignore the PSC stuff until the basic controllers are dialed in.
In general it’s not a good idea to both set CRUISE_SPEED/THROTTLE and ATC_SPEED_FF. You’re basically doubling up on the feed-forward.
The speed controller is working reasonably well though. As mentioned before it is a bit noisy so you might get a slightly smoother result by reducing ATC_SPEED_FLTE from 10 to 5 but it may not actually make much difference.
EDIT: I’ve recreated the issue with new log files not being created and added an issue here.
EDIT2: I see you’ve got BRD_SAFETYENABLE = 1 (the default) but maybe the board doesn’t really have a safety switch? Could you try setting this to 0 to see if the log creation works correctly (e.g. LOG_FILE_DSRMROT=1)
With BRD_SAFETYENABLE=0, LOG_FILE_DSRMROT=1 and LOG_DISARMED=0 I am not getting any logfiles when I arm the vehicle… Here’s a screen capture from a mavproxy interactive session:
EDIT: After a reboot I am getting different behavior, namely, the autopilot is working as expected, creating a logfile after each disarm/arm cycle. I still have the hunch that there is some sequence of events that causes the logfiles not to work as expected and if I figure it out I’ll let you know. But this is really going to speed up my testing and tuning because its easier to manage many small logfiles compared to one large one…
