Also when Tuning the rover should the NAVL1 parameters be all set to zero?
I am currently doing some preliminary tuning indoors due to a storm here in Sydney.
Getting nonsense data as I believe the speed is derived from GPS and IMU.
When I do a spot/pivot turn in steering mode
I get this
pidacheived hardly moves.
Just trying to go through the wiki to see if any questions pop up before I go outside to test.
Also I noticed that I keep getting a warning in the terminal window saying … This has been the case since I starting using ardurover …not just RC4.
[ WARN] [1515396895.563497298]: GP: No GPS fix
[ WARN] [1515396926.562950342]: GP: No GPS fix
[ WARN] [1515396956.563487449]: GP: No GPS fix
while on mission planner it says RTK fixed (currently indoors sitting under a gps repeater)
Esa,
If you’ve installed the latest beta (3.2.0-rc4) then the name of the firmware should be APM:Rover V3.2.0-rc4 (d7ceba8c).
To make ACRO mode available you’ll need to use a Beta version of the mission planner (or perhaps some other GCS) or directly set one of the MODE1~MODE6 parameters to 1.
There shouldn’t be any need to set the NAVL1 parameters to be zero. They won’t be used in Acro or Steering mode. They’re only used in Auto, Guided, RTL and SmartRTL.
We occasionally get Travis failures when the travis servers (nothing to do with ardupilot) hit temporary issues. I’ve kicked off the failing job and it’ll probably pass this time.
Re the GPS message, I’m not sure what that is or where it’s coming from. It’s not a string that ArduPilot outputs. These are the startup messages I see in the Mission Planner’s Flight Data, Messages tab.
Set HOME to 36.32434 138.6393 at 948.03m
EKF2 IMU1 is using GPS
EKF2 IMU0 is using GPS
EKF2 IMU1 Origin set to GPS
EKF2 IMU0 Origin set to GPS
u-blox 1 HW: 00070000 SW: 1.00 (59843)
EKF2 IMU0 tilt alignment complete
EKF2 IMU1 tilt alignment complete
Failsafe trigger 0x1
PX4v2 00410038 30365104 30353333
PX4: fc469199 NuttX: 1bcae90b
APM:Rover V3.2.0-rc4 (d7ceba8c)
EKF2 IMU1 initial yaw alignment complete
EKF2 IMU0 initial yaw alignment complete
GPS 1: detected as u-blox at 115200 baud
hmm I’m using the binaries found here
http://firmware.ardupilot.org/Rover/latest/navio2/
is this not the place for it?
As for the GPS warning …maybe that is a navio2 thing … I will chase this up in the emlid forum.
Not a major issue just annoying seeing the warning every few seconds
Esa,
It would be better to use the “beta” which is here: http://firmware.ardupilot.org/Rover/beta/navio2/
Have you posted a log anywhere? Maybe I can have a quick look and see if there is anything obviously wrong anywhere.
Hi @rmackay9
Today I tested out RC4 beta. I used the beta link that you suggested.
It was very stable.
As for tuning adventures. I still have issues. Rather than clog up this thread.
I’ve posted my problems here
https://discuss.ardupilot.org/t/need-help-with-tuning-rover/23192/4
The log file in that post.
Thank you
Esa
I also noticed that this parameter is not mentioned in the wiki
ATC_STR_ANG_P: Steering control angle P gain
Is this value only used when tuning NAV or is it also used for tuning the steering rate?
Esa,
I haven’t documented the ATC_STR_ANG_P parameter yet because it’s only very rarely used. It’s only used in Guided mode when a SET_YAW_SPEED or SET_ATTITUDE_TARGET command is received from the ground station or companion computer.
In future versions we may use it as part of the pivot turns for skid-steer rovers… but not yet.
Hi,
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.
Here’s a link to the log file: https://www.dropbox.com/s/av4aqwoy78koxeq/18-01-10_09-06-38.bin?dl=0https://www.dropbox.com/s/av4aqwoy78koxeq/18-01-10_09-06-38.bin?dl=0
Thanks,
Kelly
Kelly,
Thanks for the log. So a few things stand out:
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
Many thanks
Max
Would restricting the SERVO1_MAX and SERVO3_MAX solve your problem max ?
I would assume by restricting how high the pwm values can go will reduce your maximum speed
Esa,
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?
regards
Max
Max,
I’ve somewhat updated the control modes page on the wiki but in any case…
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.
hope that helps. Thanks for testing.
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:
I also hope that Michael Oborne can make this small change to the mission planner soon: https://github.com/ArduPilot/MissionPlanner/issues/1719
Of course we will continue to improve rover in future releases adding better object avoidance, etc.
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”.
The log is (I hope) at https://1drv.ms/u/s!AsZN_h-c802JiGaBBxnzceu-t8zq
Thanks
RoboBill
RoboBill,
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…
Please use EKF3 for experimentation with range beacons. EKF2 did not get this fix: https://github.com/ArduPilot/ardupilot/pull/6476.
Data rate is 10Hz which is OK.
Dear Randy
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
Regards
Max
