@rmackay9 I am looking forward to trying out the beta! In the meantime I have been working on the tuning and have made some good progress. By setting WP_Radius to a larger value (1.5 meters) I can get the rover to turn much closer to the waypoint.
But there are a few other observations that I have noticed. As this is my only mower I have to sit on the mower and mow the yard often while manually driving the mower with the RC. I tend to go back and forth from Manual to Acro mode. This switching has led me to discover some issues that may or may not be considered normal and my also influence the turning issues mentioned in this thread above.
The issue happens when a turn is made (no matter how small or big) in manual mode. After a new heading is achieved, I switch to ACRO/Steering mode with the expectation that the rover will hold that heading similar to commercial autopilots in marine and aircraft environments. Instead, the rover will always make a large correction the left or right (which has led to some scared trees and the mowing over of a bush!). The solution is to get on the new heading and wait about 4 seconds before switching. I found that the I-Term is the source of this issue and the only way I could fix on my rover was to increase the P-Gain and lower the FF-Gain. My I-Gain must remain high or the rover will not stay on course or go in a straight line. This took a lot of testing to get to this conclusion but seems to work. I feel that the same thing was happening in Auto mode after a pivot turn where leftover I-Term is affecting the heading directly after the pivot. To me it would seem that on mode switch or pivot turn all the “I-Term Memory” should start back at zero.
With these setting I am successfully getting the rover to mow a half acre field behind my house with not much touching up afterwards! So overall it’s a success but some improvements are still needed for tight navigation required in a normal yard.
My largest challenge at the moment is the Here GPS/Compass is consistently changing its heading and I have not found a good solution. Perhaps I need to find a better compass?
Thanks for this very detailed investigation and feedback…
I think you’re right that I-term is the issue and that we should reset it. This turn rate I-term should only build up in non-manual modes (i.e. acro, steering, etc) so I suspect the jump is the remaining I-term from the last time the vehicle was in one of these modes. There is an easy solution we could try which is simply to add a “_steer_rate_pid.reset_I()” call here in APM_Control where it checks whether it’s been more than 0.2 seconds since the turn rate controller was last run (not expecting you to dive into the code, just adding it as a reference).
I think I will add this, give it a quick test and if it seems ok, add it to Rover-3.4-rc1…
While I don’t want people to stop finding bugs. part of this is mechanical as well. When you cut off a hydraulic motor, it doesn’t stop immediately there is still some pressure in the lines. It crawls to a stop with the momentum of the machine. Then it is made a little bit worse on an uneven surface.
Then with only 1 valve open like when turning, there could be a slight variance in pressure versus have both valves open.
When the motors aren’t under any pressure they sometimes freewheel, like a brushed motor. IE it is running and you can push it, or it rolls down a hill by itself.
Slowing down is probably the easiest way to get it more accurate, but i don’t think it will be 100% accurate. The one non-software thing that might help is increasing rolling resistance like add 200lbs of weight\ to it when you aren’t on it.
@Kevin_Groba, I have done the same as you in disconnecting the lever dampers on my mower and connecting actuators in their place. I am using linear actuators with control boards that make them act as linear servos. They are working well except that they are a little slow, making the response a little laggy and I worry about their life expectancy. My parts are listed in the description of this video: https://youtu.be/kyI7HjmpcVM. I was wondering if you would share what model servo you are using. Thanks!
Madflower, I believe you are correct with some of the issue is mechanical. But with that said, the latest release has worked wonders with this application and I am very happy with the latest resuts.
kktrussell, I started with liner actuators and found they were too slow as well, also the cheap ones I had were not reliable at all. I searched around and found some high torque servos (Hightech D-845WP 32-Bit, Monster Torque, Waterproof, Steel Gear Servo) . They have worked better than expected! The biggest problem I have is that its too fast and not quite enough throw, but I can correct with a different servo horn. I am not sure if they will hold up, but have done well so far.
Thanks. I will take a look at those. The Actuonix ones
(https://www.robotshop.com/en/p16-linear-actuator-50mm-2561-12v-potentiometer-feedback.html) I am using have a perfect stroke length for my Bad Boy mower but max speed is 4.8 mm/sec. They have 250 Newtons of force at 2.5 mm/sec, which is about 56 lbs. They have one that is 4 times faster but 4 times weaker. At $90 a pop, I’m hesitant to try them.
Kevin, with the Hitec programmer you can adjust the speed of the servo. You may be able to squeeze a bit more throw out of it by changing your servo endpoints in APM (SERVOx_MIN / MAX) - by default they are 1100-1900, and from the Hitec’s I played with, they responded all the way from 900-2100.
Mroberts, I have set the throw as you have mentioned in Apm and I can confirm it works from 900 to 2100 as well. I think slowing down the speed would be a great option. I might have to look into that.
@mroberts, thanks for the input. I will probably keep the linear actuators until they fail and then switch to something else. Interestingly, I have a difficult time driving in manual, but I have somewhat gotten the hang of it, but I have tuned the Auto PID loop pretty well. I am amazed at how well it is controlling giving the really bad lag in the controls. In the screen shot attached, I did not have pivot turns enabled, because I only wanted to tune the main steering. So, ignore the overshoot at the turns. The width of the yellow line is about 2 feet so I think the rover is only varying about 6 inches. I was doing this in the dark, as that is about the only time I have had to work on the project lately, so I didn’t get any video of the actual mower. I hope soon to be able to work on it in the day! Still more tuning to do, but promising I think.
For a good while now, I have had trouble with “Mode Change Failed” when trying to switch to Auto with Ardupilot armed. I have to disarm, switch to Auto and then rearm. I need to figure out this problem. I also have “Bad AHRS” a lot. I have compasses disabled because I had the same trouble Kevin has had getting them to work. I assume it is my mower’s large metal chassis and/or the engine spinning. Once I get into Auto, I have had good success with tracking as you see from my previous post. But it is frustrating getting this message.
Today I upgraded to ArduRover V3.4.1-rc1 and now when I switch to Auto and then arm, the robot takes off fast and basically out of control. I read the comments here Rover-3.4.0-rc1 released for beta testing! and assume this is sort of what is going on. Anyway, the main thing is I need to figure out why I am having the “Mode Change Failed”. I am uploading a log from today. Any help is greatly appreciated!
The “Bad AHRS” message comes from the EKF not having a good position estimate and this normally happens when the GPS data is not good and waiting fixes the problem. It could also be caused by the compasses being turned off though.
So a few things from looking at the logs:
ARMING_CHECK has been set to zero. If at all possible it’s best to leave the arming checks enabled. I understand this may lead to a failure to arm but then really the best solution is to figure out and fix the cause of the failures.
both GPS_TYPE and GPS_TYPE2 (i.e. two GPSs) are enabled but the logs only show data from the 2nd GPS which I guess is connected to Serial 4/5. I don’t think it causes any real problems but it would probably be best to figure out what’s wrong with the first GPS or, if there’s really only one and it’s connected to Serial4/5, set SERIAL3_PROTOCOL = 1 (for mavlink) and GPS_TYPE = 2 (for Ublox) and GPS_TYPE2 = 0 (for disabled)
the GPS is getting a surprisingly low number of satellites 13 at the beginning and drops as low as 7. A good modern UBlox 8 GPS with a decent antenna should be getting more like 18. Numbers like 11 or 12 are normal for the older Ublox6 GPS… which should be fine actually although I wonder why they drop so badly later in the log. Any ideas?
as you say, all the compasses have been disabled (COMASS_USE = 0). This isn’t a supported configuration I’m afraid. The EKF really needs to know which way it’s heading and without a compass it will have a hard time doing that. It is possible for the EKF to figure out it’s heading using only the GPS movements but the vehicle needs to be moving first for that to work and it can take some time for the EKF to determine the heading. Are you facing the vehicle north when you first turn it on? I think this would help because the EKF would probably default to thinking it’s facing north. Still, I think we’re going to need the compasses on to work. As a side note, I think we probably need to add an EKF/GPS failsafe to stop the vehicle from acting crazy when the EKF is very confused.
I was thinking…
Depending on whether you can determine the major source of your compass errors (chassis versus the motor), if it is the motor that’s really causing your problem, then you could have the Compasses on for start-up, calibration, and then once you have a good EKF and GPS fix and are ready to start, turn off the compass? As long as you keep moving the EKF can get heading from the GPS (though it is no where near as accurate since GPS only updates at 1HZ)
Ardupilot code needs a GPS update rate of at least 5Hz. Anything bellow that will cause strange error messages and/or erratic behavior. @lordneeko please do not use 1Hz GPS devices.
@rmackay9 Thank you for the detailed and very informative reply. I have a GPS with compass I am not using. I just started to connect it and see that a wire is broken. I only have about 30 minutes to run right now, so I won’t try to fix it. I did try powering up with the unit facing north and that did make the heading correct. I am running right now very nicely between waypoints in auto. I will report back when I get compass working.
On the number of satellites: I usually see 12-15. I am not sure why it dropped lower except at the very end which would have been when I drove it inside my metal shop just before turning it off. I just had a good run of about 30 minutes. I saw 14 and 15 satellites when I noticed. I will examine those logs later. I shot a video (in the daylight for a change) of the mower and will get it posted as well. I thought I have my RTK worked out, but I see that I am still having trouble there. That’s a whole different story for another time. Thanks so much for all the help!
OK, so we’ve got the GPS performance issue solved and we can rule that out. txs for that.
It’s becoming pretty clear that we need to come up with an alternative to the compass for stabilizing the heading. We’ve done some work to use forward facing optical flow (on multicopters). We never completed that work but I think we should revive that and try it with Rovers. That’s a chunk of work though that is backed up behind some other EKF work to do with external vision system support (VICON, etc)… so I think we’re going to have to find alternative solutions for a couple of months at least.
