As requested, here is a log file showing my yaw-related issue. For background: I can fairly reliably reproduce a scenario where I start the rover and yaw is mostly accurate. I drive around in Manual (or Steering) mode and make some turns. Within a minute or so, I get an EKF-related “yaw realigned” message from the AP, and the yaw is adjusted to something other than the direction the vehicle is pointed. This may happen multiple times, with the yaw being adjusted to a different value each time. I can also reproduce this by running a mission with yaw set correctly. The mission runs perfectly with no wobble at first, until yaw is adjusted.
I’ve seen this on 3.2-rc3 and on -rc4 (which I’m currently running). The compass is a newer Here mounted on the nose of the vehicle.
from the COMPASS_DEV_ID (723977) the vehicle is using the new ICM20948 compass so for now, the COMPASS_ORIENT should be set to “26” (and reboot the board). By the way, the device id can be turned into a human readable string using the Tools/scripts/decode_devid.py script but I hope to make this easier by adding more parameter descriptions soon-ish.
COMPASS_EXTERNAL2 and COMPASS_EXTERNAL3 should be set back to 0
might as well set COMPASS_MOTCT to zero because it’s not supported in Rover (although it does no harm).
I think the first item is likely the cause of the problems but I’m not actually 100% sure. Maybe you could set that for now and try again and if that doesn’t resolve it we will ask Paul Riseborough to have a look.
EDIT: we resolved Kelly’s compass calibration issue by setting COMPASS_OFFS_MAX to 2000 or 3000. I’ve added this extra knowledge to the compass calibration wiki page.
I am now using your rc4 FW with a skid steer chassis. It seems to me working well. However the motors are too fast making it too sensitive. I want to slow the bot down dramatically.
Until I buy some lower speed higher torque motors what is the best way to limit the speed. Would it be through the transmitter or via MP parameters.
Which ever the imposed limits would need to be effective in manual and auto modes
Yes, reducing the range used for output would probably help. It would be best though to raise SERVO1_MIN and SERVO3_MIN and reduce SERVO1_MAX and SERVO3_MAX. The range above and below 1500 should be the same normally. So for example MIN of 1300, MAX of 1700 gives 200pwm both up and down.
Thanks guys for the replies. Can anyone tell me the difference in practical terms between manual and steering mode as I have tried them both and I can not see a very obvious difference. Having said that in steering mode the bot seems to turn faster on the spot.
Also is auto mode like steering mode but it drives to waypoints?
In steering mode, the transmitter’s heading stick controls lateral acceleration… which means you’re controlling the G force you feel as you go around corners. This should mean it turns faster at low speeds but slower at high speeds. The throttle stick controls the vehicle’s ground speed. So for a given throttle stick position, it’ll always drive at the same speed even if the vehicle is driving up or down hills.
In manual mode, the transmitters heading and throttle sticks go directly out to the motors (after passing through the mixer in the case of skid-steer vehicles). This mode doesn’t require GPS. The steering response, especially at high speeds will be much larger in manual mode compared with steering mode. The throttle goes straight out to the motors so you’d expect the vehicle to slow down while going up hills, speed up while going down hills.
Because testing seems to be going fairly well (knock-on-wood), I’m thinking of pushing Rover-3.2.0 out as the official live version within the next 3 days or so. If people have any objections please speak soon!
The final version will be just like -rc4 but also include these small changes:
send live PID values to ground station regardless of mode (commit is here)
New release… great… but has anyone else been able to use the POZYX system. I get “EKF IMU0 has stopped aiding” while in manual mode. When I switch to auto, I get “Bad GPS Position” followed by “Flight mode change failed”.
I’ve had a look at the logs and I wonder if maybe there is a problem with the update rate and/or beacon data being sent to the autopilot.
In particular the BCN.D1 value (the 2nd beacon) seems to always be 3.389. Also the distances to the beacons don’t seem to be changing very often. It could be that the distances really aren’t changing but I suspect that it’s actually that the updates are very slow to arrive. I think the distance to each beacon needs to arrive at at least 4hz. In my setup I was managing around 7hz.
EDIT: Paul Riseborough will also have a peek at your logs…
Thank you for your answer. This is now very clear.
I have a question that is a little off subject. I am looking to understand rover software code. I can write simple arduino and c++ programs however my programming skills are not great however I want to attempt the following.
Do you know of any tutorials that really explain in detail the ardurover code. I need an overview of how the main elements of the code work.
Also I am looking to find a cut down version of ardurover I want to find the code for a gps waypoint driving rover. I do not need endless possibilities as I only want the rover to drive between waypoints with a gps and compass and to be able to pivot turn and do 180 degree turns at each WP. I ie I want to the rover to navigate a simple grid.
The code can be reasonable simple as I do not need to use the code on may chassis or many different motor controllers etc etc. I will then develop it as a learning exercise. I would like to do this as I think understanding ardupilot would be a major task and will take a long time before I got anything that I can use for my own projects
If you know of something suitable then I would appreciate a link so I can take a look
Of course I will continue with ardurover on my other projects
Thank you! I must confess I’ve modified the Arduino sketch just a bit.
Since I’m a rover, I removed the changing from stage 0 to 1.
I commented out the changing of the TxPower for the anchors & tag. Standard power level works fine.Besides, the change power function didn’t work that well.
I changed the code for get_remote_range of reading the anchor to anchor distances to setting those anchor to anchor distance to what I measured. I did this because there were too many inconsistencies in the doremoteranging function.
I added code to read a rotating LIDAR LITE V1 so my robot won’t run into anything unexpected.
I added code to send all the data from the POZYX & LIDAR Lite to a Megunolink GUI.
As I mentioned sometime ago, I really don’t understand all that is sent by the Arduino to the Pixhawk, so it would not surprise me if my fiddling is to blame. For example, it is my belief that the doremoteranging is just between anchors. If this is wrong, please let me know.
I’m afraid I don’t know of any cut down versions of ardupilot/ardurover. We try to layer and compartmentalise things so the complexity is kept under control but the system as a whole is not simple of course.
Rover can already do the things you’re talking about (driving a grid, pivot turn, etc) so no programming is really required I think… but it’s all open source so do whatever you think is best of course!
I think I’ve found a problem which stops Rover from going into autonomous modes unless there is a GPS. I’m currently testing with the ZED camera and it’s not letting me go into Steering mode. My vehicle is appearing on the map and I’m not getting the “IMU0 has stopped aiding message” so I think there are likely two problems in your vehicle - but one of them I have reproduced and will look into (issue raised here)
THANK YOU!!! Yes I’ve always had that “No GPS” on my HUD . I have seen that IMU0 message.
3 other issues:
I’ve also been having to deal with Compass variance errors. Per the wiki page you previously mentioned, tweaking the EK2_YAW_M_NSE seems to have helped… at least yesterday… not today.
I looked at my D0 thru D3 values in the log and it makes no sense. Assuming these are anchor to tag distances, then something is wrong. As I manually drive around, I’m sending D0 to D3 values to the Pixhawk ranging from 300 to 7000 mm. But the logs values do appear to be constant with an occasional small “burp”.
While in manual mode, I can track my movements on the MP, but the tracking is still 90 degrees out of whack. I’m still experimenting with the Yaw.