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.
1 Like
My actuator setup is attached. You can see the disconnected damper beside the actuator. They were pretty easy to install but they are slow to operate.
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.
2 Likes
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!
I’m not sure I the log file uploaded. It is also here: https://www.dropbox.com/s/t30jo3g6o6x3nea/00000022.zip?dl=0
Kenny,
Thanks for the report and logs.
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)
2 Likes
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.
Chips interpolate between time pulses. But GPS time pulses are 1hz
I have had great success with the Firgelli Actuators
1 Like
I have a 5 Hz update rate.
@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.
1 Like
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!
1 Like
Kenny,
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.
Looking forward to the video!
I bought a couple of different I2C compass breakout boards but have not had time to wire them up. I also have the one compass/GPS module that I will fix and try again. The PixHawk is setting right above the roll bar of the mower so I figure that is interfering greatly with the magnetic sensor. I have a proper enclosure coming in for my electronics and plan to move it away from metal as much as I can. I also bought a second PixHawk and think I will wave it all around with the mower running and see where it seems to work best. I can also plug one of the better compass modules into it to see how they work in various locations. I may try a longer I2C line, but I’m sure at 3.3V I2C can’t work too far.
So, how do you determine what an individual compass is reading in Mission Planner? The AHRS heading, being a blend from the EKS doesn’t work, of course.
Video coming up in a few minutes.
1 Like
Kenny,
So on the mission planner’s Flight Data screen, there’s a status tab near the bottom left. a huge bank of labels and numbers is shown, the mx, my, mz shows the individual values for the first compass, also the “magfield” shows the length of the vector made up of those three value.
there are similar fields for the 2nd (mx2, my2, my2, magfield2) and 3rd compass (mx3, my3, myz3, magfield3). It’s also possible to see these numbers more easily from the Quick screen by clicking on any of the existing numbers in the Quick screen and then selecting the appropriate checkbox on the window that pops up.
The magfield values in particular are useful for seeing how bad the compass interference is in real time. So you can move the compass closer/further from the body of the vehicle and see at what point is stabilizes. Ideally we should aim to place the compass somewhere that it’s magfield doesn’t change by more the 30% from it’s “natural” lenght. I.e. take it 10 feet from the vehicle and it’ll probably give a lenght of something like 450… move closer and closer but once it’s length is over 600 then it’s too close. These numbers are just guesses and examples and the length can be different depending upon the compass hardware itself, the environment in which it was calibrated and your location on Earth. Anyway, hopefully that gives some ideas about how to determine a good place to mount the compass.
By the way, ArduPilot only ever uses one compass at a time and by default it’ll use the first compass (which is normally an external compass). We can add support for blending compasses, it’s not particularly hard we just haven’t done it yet.
Thanks, Randy. I had seen the mx, my and mz fields (and the 2 and 3 versions) and pretty much understood them but thought maybe there was a single value of azimuth degrees. I did not know about magfield. I will get more familiar with all that when I get a working external compass hooked up.
In case it is of interest the log file for that run and another lap or two and then manual driving back into the shop is https://www.dropbox.com/s/rc3p36o4d0nql38/00000024.zip?dl=0, I’m always open to advice, comments, etc!