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”?
The origin is always referenced to the body frame. Yours should be the center of your rear axle.
2 Likes
Thank you. I will keep that in mind.