Good morning. I have been testing a large tracked platform and attempting to get it to work in auto mode. The issue is seems to be only when the rover is turning to the left. If I run a serpentine pattern, it seems like when the rover turns to the right, it works close to perfect. There is still a little bit of oscillations, but overall it performs okay. When the rover goes to the other end of the pattern or path, and attempts to turn to the left (line spacing set at 5m), it appears as if the rover hits some sort of limit or cannot turn sharply enough as it slows way down at the waypoint, shutters very fiercly, then makes a very wide turn to the left, overshoots back towards the path it is supposed to be on (the yellow line), and then oscillates with what looks like throttle and steering for some time until it finally gets back on the correct path and then performs fine. Is there a way that I can get some information or help on this issue please? I know that @Yuri_Rage was working with me on the last post I had on this issue but I have since went back to an earlier version of ardurover to try to simplify things for myself. Attached below is a photo of the machine I have been attempting to tune.
Reverting from 4.4 to 4.3 won’t fix any issues (and is more likely to cause them).
Recommend you use 4.5.1 stable and post some log data.
I will attempt to re-upload the firmware to 4.5.1 and do some further testing then I will post some log files. Thank you.
Your problems aren’t likely related to the nav controller, but rather lower level tuning, if tuning is to blame at all.
Issues turning one direction vs another are far more likely mechanically related than firmware config.
Can you drive in manual mode?
Can you drive in acro mode?
Does behavior in acro mode meet expectation (like a refined version of manual mode)?
If the answer to any of those questions is no, then auto mode is out of the question, and you need to fix the mechanical issues first, then address the tuning.
I have done a bit of testing in auto mode making right hand turns and am currently downloading the log files. I will make a new topic in the correct group and upload my log file momentarily. I only tested making right hand turns for now to make sure that everything is working properly. After you take a look at the logs, I will re test in both a clockwise and counterclockwise pattern to verify that everything is working correctly. Thank you again
Tagged this thread with 4.5. There’s no need to keep spreading this topic across categories. Best to continue it here.
Okay thank you. It appears as if the left turning issue was just a loose wire that came about yesterday as it was tough to turn left in manual mode this morning as well. I have since fixed this issue before auto testing today. This morning, after I uploaded the rover 4.5 official, it seems to track very well and no oscillate much, if at all. There is a slight issue in cornering (when it turns correctly) that I would like to solve as it seems to turn before the waypoint and then get back on to track later. The problem is, if I decrease the waypoint radius to 0.25m or below, then the rover wants to stop at the waypoint, and turn ‘inside’ (the wrong way) until it gets stuck in a toilet bowl motion and I have to switch it into manual mode. To combat this for testing this morning, I just kept the waypoint radius at 0.5m so the rover would turn the correct way towards the next waypoint. On the uploaded path that I will attach below, it appears as if the rover is behaving correctly at waypoints 2,3, and 4, but when it goes to make a turn around waypoint 1 it seems to over steer and then struggle to get back onto the path for a little while making steering oscillations. Thank you again for all of your help and I look forward to seeing what we can make of this situation. I will attach a google drive link for the .bin file in a reply to this comment.
You’re in good hands with Yuri but I’ll throw in my 2 cents as well. Thanks for the log by the way.
I think CRUISE_THROTTLE should be increased from 20 to about 50 or 60.
Here’s a graph of the throttle output (in red) and the speed (in green, scale on the right). so it looks like it takes about 60% throttle to achieve 0.9m/s.
For steering control it seems to be overshooting in some places and undershooting in others which points to some kind of ESC issue. Is it possible that maybe the vehicle can’t turn while moving? I’ve seen some motor controllers where it can only do one or the other. E.g. it can move forward or it can stop and turn but it can’t drive in a circle.
I will attempt to change the throttle settings this morning and re-test.
As far as the steering portion, in manual mode the machine is fully capable of turning in a circle both wide and pivot turning. So I do not think the ESC would be the issue but I could be wrong. I was doing some reading and for some reason was thinking that it could be I term buildup somewhere that releases on the overshooting portions? Is this accurate, or did I go too far down a rabbit hole?
During that log file that I shared, I believe I did mess around and change the FF setting if I remember right. That may be the discrepancy in the overshooting and undershooting. I will complete a log file here in an hour or so with a constant FF that I believe fits the best and with the corrected cruise throttle setting to see if that fixes the issue. Thank you for your suggestions!
The section of the log presented by Randy above is 4 minutes after your last change to ATC* parameters, and it shows the anomalous behavior he mentioned, where there are overshoots followed by undershoots in rapid succession.
Again, we must rule out mechanical/electrical issues before tuning can be effective. Do another good once-over of the system to rule out gremlins like you found earlier in the discussion. And then…
When driving in manual mode, is turning sluggish when forward speed is low? I tend to agree with Randy that the motor controllers are producing varying output with speed, but it seems to be opposite his assumption. In the graph below (with your most aggressive ATC_STR_RAT_FF), we see steering overshoots at speed and undershoots as speed decreases. Speed is scaled up by a factor of 20 to show correlation to steering:
I see you have MOT_SLEWRATE turned down to 50. While I don’t think this is causal, does behavior improve at all if you reset it to the default of 100?
Also, are you using any additional hardware between the Rover’s motor controller and the autopilot’s servo outputs? (I worked with a vehicle like this one and used a microcontroller as a signal interpreter, which can be tricky if not done well)
If not, do you happen to know what motor controller is in use? Is it programmable? Is there an instruction manual available?
I went through the system again this morning. When I first started up the rover, I switched the cruise throttle all the way up to 55 as suggested and it actually seemed to hurt the rover’s navigation. As a result, I kept lowering the throttle down until I found a higher, but suitable option of 35. After some more testing, I then started to realize that maybe the compass was the issue as it seemed to be drifting a little bit during the course. After messing around with the compasses a little bit, I did a large vehicle mag calibration and began another new mission of just a square. To my surprise, the rover acted very responsive to these changes, as well as adjusting the max turning speed from 35 degrees to 30 degrees, decreasing the accel parameter from 0.5 to 0.2, and also raising (I forget the actual name of the parameter) the parameter that weights steering vs throttle prioritization from 0.5 to 0.8. and received very very good results that I will link below. I would greatly appreciate if you would take a look at my log and see if this may just be a fluke, or if these changes actually did make the improvements that I was looking for. To my eye, it appears as if the rover just needs a tiny bit of improvement around the corners to smooth them out a bit more and the rest seems to be very acceptable to me.
Briefly (I’ll look more shortly), you are shooting in the dark by messing with the speed feed forward (CRUISE_SPEED/CRUISE_THROTTLE).
Both of these logs clearly show a throttle output of near 60% to achieve 0.8-0.9 m/s, making Randy’s suggestion of CRUISE_THROTTLE=55 valid. If changing that parameter away from 55-60 makes a difference in steering behavior, then it is an offsetting error, and more tuning clearly needs to be done.
Should I wait for your suggestion after further review of this log? Or should I attempt to change the throttle output to 55-60 and attempt to re-tune the rover with that setting from the get-go?
Set CRUISE_SPEED=0.9 and CRUISE_THROTTLE=55.
Leave those alone. Consider them tuned.
Thank you for your suggestion. I will set those as the settings and will not touch them any further. I did notice that when I first implemented those settings this morning, it seemed as if the rover was very very touchy around corners and during acceleration. Is this because I need to further refine the speed and steering controllers?
There’s a big spike on initial acceleration, presumably because current spikes to get things moving and then settles out. We can try a lower MOT_SLEWRATE to combat that a little (opposite my previous question about that parameter). The speed controller seems pretty responsive to throttle input, so maybe 25 could help tame it.
We can also try a little bit of ATC_SPEED_D (start at 0.01).
Steering is much improved, so your gut to change ATC_STR_ACC_MAX and MOT_STR_THR_MIX was probably correct.
I think you can safely reduce ATC_STR_RAT_FF as well. Try 0.3-ish.
Since you’re using a Cube Orange and the tuning so far has things fairly tolerable, you might try the QuikTune script and see what results it produces. It will often outperform manual attempts.
I will try to implement those changes to see if anything improves. I am out testing now and changed the cruise throttle to 55 and it performs very very similar if not the exact same as throttle at 35 so in my eyes, that it a good sign. I will implement those changes to see if anything improves. Thank you again for all of your help
Sorry for the delay in responding, as I have been out testing a lot in the last week or so. I have made the changes that @Yuri_Rage and changed ATC_STR_RAT_FF to 0.31 I believe is what the final number was. On top of these additions, as well as changing to a GPS for YAW configuration, using two GPS units for heading instead of a compass, coupled with an RTK base station, I was able to get phenomenal results. The large tracked rover was able to complete a larger square pattern over 50 times and turning at the same exact spot in all four corners every single time. The only thing that I have noticed is that when it receives its correction data (you can hear the motors whine as they are moving) it is a little bit more “jumpy” than I would like. Is there a way to smooth out this jerkiness without the rover swaying too far from its desired “line” between waypoints?