Flight vehicles ‘pivot’ about the centre of mass, ground vehicle with steered wheels rotate about the non steered axle. If the all the *_POS_X,Y,X params are set up relative to the non-steered axle, then a yaw rate won’t produce a cross-track velocity. This should make the L1 trajectory controller easier to tune. The c.g. position is largely irrelevant for this application.
2 Likes
It seem that the GS would just not discover the udp client/server, I’ll try to post the settings once I get the basic tuning done in 4.0.1 this week!
@Yuri_Rage are you able to provide a log with LOG_DISARMED=1 and LOG_REPLAY=1 with the IMU position, GPS position etc all set relative the centre of rotation? If you drive in RH and LH circles then I can determine by looking at the innovations and other data where the inconsistency is occurring.
1 Like
Code inspection shows that the WGS-84 output from the EKF is not being corrected for the IMU to body frame origin offset whereas local NED frame outputs were. This will be fixed by https://github.com/ArduPilot/ardupilot/pull/18264#pullrequestreview-725113538
3 Likes
To add some more detail to what Paul says, it turns out the issue was that we weren’t re-applying (un-applying?) the IMU offsets in the AHRS/EKF get_position() method.
So my suggestion was that we should move the GPS data to the middle of the vehicle and fuse it there. It seems the way the EKF is written though, we should first move the GPS to where the IMU is and fuse it there but then right at the end, once the EKF has created its position estimate, we move that whole estimate to the middle of the vehicle. So the IMU offsets are used twice… move all the sensor data to the IMU, then move the final produce to the middle of the vehicle.
Tricky stuff but super happy that we’ve gotten to the bottom of this.
3 Likes
Thank you all for taking a look!
@priseborough - would you still like those logs? The request appears overcome by events.
I should’ve chosen my words more wisely (above), and I see where I implied that center of mass might be important on a rover. My intent was center of Z-axis rotation, or the non-steered axle as you say (which could possibly confuse some folks when discussing skid steering).
I had a feeling the code fix might be a little more complex than the one I tested for myself, and I truly appreciate the more in-depth look.
I’ll build 4.1.0 today with the proper AP_NavEKF3_Outputs fixes in place of the AP_NavEKF3_PosVelFusion band-aid that Randy and I discussed and likely move the entire project to the 4.2.0-dev branch soon.
1 Like
I’m also planning on releasing -beta7 some time this week and this will include the fix.
4 Likes
I can wait that long 
I thought perhaps it would be a 4.2 feature, since the PR changed a file that includes other 4.2 specific changes. I tried a 4.1.0-beta6 branch build with the entire file from the PR, and it broke due to compass function call changes, so I had to copy and paste the 3 changed lines into the 4.1 file. Glad it’s being incorporated sooner!
3 Likes
I was playing a bit with 4.1.0 beta6 and a u-blox F9P. The result is a tiny infinite WP-loop on the balcony, from which I was surprised that this is really working.
But see yourself: https://www.youtube.com/watch?v=Z0euGkhf5sk
3 Likes
@priseborough, @rmackay9 and @Yuri_Rage, Just wanted to chime in to say that Yuri sent me the .cpp file with the sensor position fix. I ran beta6 with that file and I have beautiful pivot turns for the first time ever after setting the IMU and GPS positions. My GPSes are both offset from the center or rotation and the IMU is offset a good bit from the center of rotation. With this fix, all is compensated for and works well. Thank you!
2 Likes
After my experience with the tiny WP loop on the balcony, I wanted to know a little more about the accuracy that can be achieved with a u-blox F9P RTK setup in combination with a seperate F9P base station.
See https://www.youtube.com/watch?v=A2b71N5aC0Q
My conclusion is: The accuracy is somewhere with in about 5cm radius CEP50
During the test I noticed the following things:
-
InternalError 0x1000000 after about 74min runtime.
This InternalError happens also sometimes with my copter after variable flight time - sometimes after 5min, sometimes after 30min, sometimes after 74min. I will put a shorter bin-log in the copter section later.
It looks to me this error code is used for “Ups … this should not happen” in different modules.
The tractor-rover is equipped with a Matek H743-Mini, compareable to the Matek H743-Slim in the copter. -
Object avoidance did not work anymore. I switched off the function when testing on the balcony. Maybe I overlooked to activate a parameter again. In the tuning window I saw that the “sonarrange” dropped below the limit (1m) for about 2s. But there was no reaction of the rover. Earlier it stopped, backed up a bit and then passed the obstacle. I will try to reproduce this later.
2 Likes
Thanks for the report. The internal error 0x1000000 is for “imu_reset”. We think this is a hardware issue with the Matek H7 boards. We’ve reported the issue to Matek. I guess we could gloss over the issue and suppress the error but we’re pretty confident that the hardware is at fault because we use the same IMUs on other boards without problems… it’s just the Matek H7 boards.
… maybe we should put a warning on our wiki page to steer people away from these boards until the problem is resolved.
1 Like
Hi @rmackay9,
yes, it is the imu_reset error. I counted the zeros in the message wrong.
What is unfortunate is that the message in Mission Planner does not disappear after it has been triggered once. The message should disappear again after the IMU is reset, similar to how GPS errors are handled. Or supperess it completely as you mentioned. I could not notice any negative effect with rover and copter when the imu_reset happens.
The small “Slim” and “Mini” get quite hot during operation.
I suspected it might be a temperature problem. But the IMU temperature seems to stay in the limit at about 60 degC.
1 Like
I use the Matek H743-Wing on one of my rovers and I do not get the IMU reset error. I never checked how hot it gets, but with all the copper in the PCB (I was barely able to solder the ground pins…) it should spread the heat easily.
Thanks for the feedback. I’ll bring it up at the developer meeting tomorrow and we will discuss what to do about the messages.
Hi Randy or Yuri- Has this been resolved in terms of the definition of centroid? Should it be the center of rear axle for skid steer rover or should it be the center of the rover?
For the GPS_POS* parameters for the GPS yaw on a rover, should they be relative to the flight control position or should they be relative to the said centroid? Thanks.
It was resolved in 4.1.0 stable.
For a skid steer Rover, the origin should be the point about which the Rover turns. Reference all offsets to that.
For best results, place the autopilot coincident with that point and use zero for all INS offsets.
1 Like
Thank you for the quick response, Yuri. In my case, I have the skid-steer motors on the rear axle. Should the origin you referred be the center of the rear axle in my case?
If so, my INS_POS* parameters are not 0 for the flight control. My additional question is: should then the GPS_POS* parameters be relative to the said “origin” above, or, should the GPS_POS* be relative to the flight control as the new “origin”?