The compass problems can be improved allot buy building a platform above the rollbar to mount the flight controller box above the rollbar.
No, there is no way to input “Manual true heading” AFAIK.
And yes, Ardupilot has a MagVar table for the entire world.
@Kevin_Groba I agree totally on the need to draw polygons that are avoided. This YouTube video (https://youtu.be/c_8d5sY455o) is an example what we need or at least a good start. It doesn’t look like the author is responding to comments, unfortunately.
I have my program about as good as I am going to get it, at least for a while. I need to clean it up a tad and figure out how to post it on github. I hope to do that today. I look forward to your bug reports!
@Kevin_Groba, et al, I have uploaded my “MowPlan” program to github. The reply (to myself ) at Auto Way-point Generation for Polygon Coverage from Outside to Center, gives brief instructions. You should be able to run the .exe from github without recompiling I hope. I would be very interested in any feed back, help, etc.
I will probably not do much more with it for a while since I think it will meet my needs and I have a lot to do on the mower. Maybe others will improve it.
This looks pretty cool… look forward to trying it out Kenny.
Hi @Kevin_Groba, Not sure if I missed it in the thread somewhere, but which board/computer are you using as the basis for your mower control? I’m trying to do something similar with a BeagleBone Blue but seem to be finding quite a few functions aren’t available yet when compared with pix hawks etc. Cheers, Ben
@rmackay9 I experimented yesterday afternoon with compasses. I had thought that I might be getting interference from the engine when it was running. I now do not think so. I believe the biggest issue I have had is that I was not turning on the Pixhawk when the mower was out in the open and not giving the compasses time to stabilize. I will be experimenting, hopefully tomorrow with doing that. I recorded a video of my compass experiments. Hopefully it will help other newbies. If you gurus see that I am off base with anything I say in any of my videos, please let me know so I won’t mislead anybody else!
I’ll be glad to share the spreadsheet with anyone. The system here would not allow me to upload it.
(I hope it is OK to keep running on this thread with somewhat unrelated posts, although this one is fairly related.)
@BenBBB, I use the pixhawk Cube.
@ktrussell, I have had many issues with compass calibration as well. I will give it a try and see if rebooting in then open will improve things. I have not found the reason that the calibration drifts, but seems to drift a few minutes of usage. I do the same as you by starting up in the garage and pulling it out of the garage in to the open under manual control. If you are correct that would explain why I have the issue only part of the time and not every time I use it. When the calibration is on the rover is mowing a field for me quite well… with the exception of cross track error. Sometimes it is off up to two feed. I have not been able to solve that issue yet. It very well could be that I need RTK to solve it, but I still need other issues resolved prior to spending more money.
Well, @Kevin_Groba, I am sorry to say that I tried a short run this afternoon, just before a rain washed me out! AND…no improvement. The good thing is I can upload the logs in case someone can help. But, I immediately had an Error Compass Variance. I disabled the internal compass and still had the variance some. I put the PID parameters in that I have been using when compass is enabled (they are different from the ones that work best without compass). I ran a square to verify that it was tracking fairly well. Then I enabled pivot turns and things went bad.
Our power went out from the storm, so I came to the house. I will get the logs from the Pixhawk tomorrow and upload.
I was impressed with the pivot turns your mower was doing in your video. I had hoped that the compass would help that work for me.
@Kevin_Groba, what did you do to get pivot turns working, by the way? I know in the thread above you discussed the problem with fast acceleration but even then, your turns looked great. I have PIVOT_TURN_ANGLE =60 and have tried PIVOT_TURN_RATE at 10 and 1. I don’t know what the units are for PIVOT_TURN_RATE. I think with my sluggish turning, the pivot turn overshoots a lot and then swings back overshooting again, basically oscillating. I might just have to wait until I fix that. I think I’m ready to mow if I could get pivot turns working.
Here is a screen shot of tracking before and after turning on pivot turns:
If you’ve got a dataflash log i can probably dig into the issues in more depth.
The scale of PIVOT_TURN_RATE parameter is in degrees/second. So even 10deg/sec is quite slow. I suspect it should be at least 30deg/sec.
From looking at the purple trail once the pivot-turns are enabled looks like the PIVOT_TURN_ANGLE is set too low although 60 should be fine. I think I’ll need a log to figure out what’s going wrong in this case.
Thanks, @rmackay9 . Logs from today are here https://www.dropbox.com/s/76rm9x9tp5a2qfr/2018-06-28%20DataFlash%20and%20Telemetry.zip?dl=0, but please don’t spend too much time on them. I am just pretty sure that my main problem is the slow speed of my actuators. This graph of desired versus achieved steering rate indicates that I think:
On a long path, I can tune the parameters to track well, but any upset that requires a quick response (such as a pivot turn) causes issues.
I had some uninterrupted time today trialing things but could not overcome this issue. Changing PIVOT_TURN_ANGLE to 75 degrees, did stop the oscillation as you suggested. I will upload a few screen shots showing the overshoot issue I still have. I could never get the pivot turn to work without significant overshoot. Changing ATC_STR_RAT_IMAX to a low value like .1 slowed down the turning speed, but even though it was turning slowly, it overshot about the same.
If you do look at the logs, know that you should be able to see what was going on early in the logs. The last couple of hours were spent playing with tuning to no avail.
I have combined several short videos I shot while running the mower today into a single YouTube video at https://youtu.be/RAy9BzSD6cM.
Some observations that do puzzle me:
The speed of the pivot seemed unrelated to PIVOT_TURN_RATE. Even though my actuators are slow, my steering is sensitive. A small movement causes a big response. I wonder if this is the cause.
Setting WP_SPEED to a very slow value such as 0.1, makes the rover slow down at a waypoint as it should, but it seems to stay that slow forever, even after leaving the waypoint. (4:18 in the YouTube video mentioned above shows this phenomenon.)
A. What makes the ArduRover exit pivot turn mode?
B. With no compasses enabled, why isn’t the heading dead on if the rover is traveling in a straight line? I would think that the GPS heading would be used and it would be accurate.
I hope to have a faster responding actuator within the next week.
Thanks for all the help!
So one important issue is that ATC_STR_RAT_FF is set to zero. This is the most important parameter to get right when tuning the vehicle. With this set to zero, the P and I terms need to do all the work and I suspect it’s the I term in particular that is causing the overshoot.
I could look into this more but really, this is such an important item that it likely dwarfs all other issues and if we get the ATC_STR_RAT_FF set correctly I think everything else will work much better. I’d start with a value of 0.3.
EDIT: the video at the bottom of this wiki page shows how I did the tuning of the FF in real time. This video is for Ackerman style vehicles but the method is quite close to what should be done for skid steering vehicles (I will make a skid-steering vehicle tuning video in the next month or so).
Randy, I tried multiple times to tune “by the book” but had great difficulty with anything at all in the FF parameter. I read that it was the most important and then it was somewhat like P and that P would be very low or even 0 with FF tuned right. I will try again, but I have tried a lot. I have worked in process control my whole career and tuned a lot of PID loops. So, I will say that I gravitated to the traditional PID without the FF. For academic purposes if nothing else, what exactly is the FF parameter doing? I understand the concept of Feed Forward control. Anyway, I will try again. I would love for that to be it! I will watch the video and try to carefully tune FF first. I sure do appreciate the advice.
I also have one other trick mechanically. I noticed the controller I bought from Actuonix for the linear actuator moves the actuator fast and then slows way down for the last movement. It does work well but that non-linearity may be an issue. It also has 3 adjustments for accuracy, speed and something else. I really have not touched those since I first set it up. Maybe I can make an easy change there.
I watched that video right when you uploaded it. It was very helpful but I guess I just figured there was something different about my big hunk of metal with slow actuators! Looking forward to trying all this later today, weather permitting.
@rmackay9 Just had to post this quick note. I can admit when I’m wrong! Started over with tuning and worked with FF. Got immediate good results! More later. Haven’t tried pivot turns yet. Thanks!
Great that it’s working better!! Looking forward to the next video (no pressure of course :-)).
Quick update: Tracking pretty well. This grid is 425 feet long, so the deviations from the yellow line are perhaps a bit much for a mower, but looks good from this far out! Pivot turns were not enabled here. Pivot turns still overshot the same. I made some screen shots while testing. I can upload later along with logs.
Yes, looks pretty good. For the pivot turn overshoot, there are at least two possibilities:
- I-term build up during the pivot turn (some improved turn-rate tuning may help if this is the case)
- the ATC_STR_RAT_MAX (maximum rotation rate), ATC_STR_ACC_MAX (maximum change in rotation rate) and ATC_STR_ANG_P (P term to convert heading error into a turn rate) can be set so that the vehicle can’t decelerate (it’s turn rate) fast enough and causes an overshoot. There’s actually a check we can add into the code to remove the possibility of this issue.
It’s possible that ATC_STR_ANG_P is too low at “1”. The new default is “2.5” although I wouldn’t expect this to cause overshoot, instead I would expect it to cause the vehicle to turn too slowly. This parameter controls how fast it will attempt to turn to in response to an angle error (during pivot turns).
Anyway, if you have a log of the pivot turns overshooting we can see the cause pretty quickly I think. My guess is it will be I-term buildup and the PIDS message can be used to confirm this.
Thanks Randy for those tips. I only enabled pivot turns for a very short time a couple of days ago after I had tuned the steering again after you suggested I work with ATC_STR_RAT_FF. I have uploaded the telemetry and dataflash logs to https://www.dropbox.com/s/vlw4w6hdqzsrfht/Logs%202018-06-29.zip?dl=0. They are huge. I only made two turns with pivot turns enabled. They occurred between 21:34:48 and about 21:36:00. That may not be enough data to tell you much. I can make another run, perhaps tonight, and do more turning in a shorter time with smaller files!
I think I found the place where the pivot turns were happening because it looks like it’s doing lots of little turns but I had some problems analysing the logs because, as you say, they are quite large and the MP graphing tool at least really slows down. If you could do a shorter test that would really help I think.