A couple of suggestions
-
set EK3_GPS_TYPE to 2. I don’t know why, but my navigation got a whole lot better than when it was set to 1.
-
use the MM Submask X&Y shift to get your rover to matchup with its actual position on the MP.
Amilcar, can you let us know when this fix is available pre-compiled in the beta firmware list in MP?
These fixes will be available on ArduCopter 3.6.0
Great. And which version of ArduRover?
ArduRover 3.3.0 … not planned yet
Not 3.2.3? Bummer. All the documentation that says to use EKF3 is now wrong, since it doesn’t work anymore. We can work around with EKF2, but we’re stuck in a undocumented state now.
I’ve just created a skeleton marvelmind wiki page. I don’t have the system so any help people can give fixing it up would be greatly appreciated. I suspect @amilcarlucas will have the most to contribute to this page but there is also a guide-to-updating-the-wiki here in case anyone else wants to get involved.
1 Like
Thanks, Randy! Great to be working with you again on cars. ROS is overkill for this and ArduRover is very solid – just a few more tweaks like this and it will be perfect.
With DIYRobocars we use OpenCV and 2D LIDAR for the main navigation functions on Rpi, and the interesting question is whether we should use Pixhawk as just another sensor (IMU and GPS) and fuse the data on RPI, or do the opposite (use CV and LIDAR) as sensors and fuse it in ArduRover.
Basic question: Is the Ardupilot-Pixhawk-Mission Planner system capable of receiving, controlling and displaying the path of a rover within the same accuracy as the Marvelmind system?
Thanks
RoboBill
RoboBill,
In terms of estimating it’s position, I think AP should be as accurate as Marvelmind because it’s using the Marvelmind sensor data and combining it with the accelerometers. MP should be able to display the position on the Map pretty accurately as well. It’s limited to 1cm of accuracy - I’m not sure if the Marvelmind has better than that …
Re control (which the marvelmind doesn’t do), it’s hard to get 1cm level accuracy in control - i.e. to make a rover be within 1cm of a specified location. I’ve never measured AP’s accuracy and it depends a lot upon the tuning of the vehicle. It’s theoretically possible to get down to 1cm of accuracy but the vehicle would need to be perfectly setup and tuned.
1 Like
That info is very helpful. I’ve been having issues getting my rover to track to each WP correctly. Now I know its just me.
Thanks,
RoboBill
RoboBill,
Well, Rover is not quite bug free yet and tuning is still a little harder than it should be… I hope to release a beta of 3.3 within the next few weeks which will improve the pivot turns.
1 Like
To get better tuning, I assume that good dimensions of the rover between C.G. and other parts of the rover is very important.
First, here is a side view of my rover. The dimensions are in meters.
- I’ve connected my Marvelmind to the GPS input of the Pixhawk.
- I still have the other cable from the 3DR GPS unit connected to the I2C input.
Everything works pretty good but tracking a simple square is consistently a bit off. So I need to verify some dimensions…
Therefore am I correct in the following assumptions:?
- The Center for Gravity of the rover is the Mission Planner origin
- IMU0 and compass0 is on the 3DR unit.
- imu1 and compass1 is in the Pixhawk
- GPS0 is in the Hedgehog.
- The IMU in the Hedgehog is not used.
Thanks
RoboBill
- MP origin is the IMU0 unless you specified AHRS_OFFSET_*
- No, all IMUs are inside the PH. ony compass 0 is outside.
- yes
- yes.
- yes
You can use OFFSET parameters to make all calculations relative to your CG, that should take you a step closer to cm accuracy
1 Like
I admit I’m still confused because if the origin is the IMU0, then what is the purpose of the parameter INS_POS1_X. But if the mission planner origin is the rover’s center of gravity, then the whole discussion of mounting the IMU close to the origin makes sense including that parameter. Currently my INS_POS1_X is .013 meters. Perhaps not a big deal, but my rover is 4 feet wide by 1-1/2 feet long and it tracks to only one side of the paths.
BTW Where does @Michael_Oborne give the definition of the "origin?
Thanks
RoboBill
I think we shouldn’t use the words, “MP origin”. There’s an “AHRS home” and an “EKF origin”.
- “AHRS home” is a lat/lon/alt that the vehicle will return to as part of an RTL.
- “EKF origin” is also a lat/lon/alt but the user is normally never aware of this unless they are doing non-GPS navigation. The EKF internally does all its velocity and position estimates based off this origin. The origin can be set in the Mission Planner by right-mouse-button-clicking on the Flight Data screen’s map and then selecting, Set-Home-Here>>Set-Origin-Here. This is required if there’s no GPS so that missions can be run and so the ground station can display the vehicle on the map.
The INS_POS* parameters are for setting an offset from the IMU to the vehicle’s center-of-gravity.
hope that helps a bit.
1 Like
Hi,
I am facing some problems trying to integrate the mm with my Erle Rover, I have followed the directions on the wiki page but the mission planner does not show the location of the rover. I am also not sure if I should send NMEA messages or mm messages. Is there a full parameters list that I can compare with?
Mien,
You’ve got Rover-3.3 loaded on the vehicle of course? Here’s the wiki page but you’ve said you’ve seen it … but just for reference.
From looking at the driver, it doesn’t look like we accept NMEA so I think the mm messages should be used.
If you could include a dataflash log (a .bin file) that would be helpful.
Mien,
did you enable “Raw distances data” on your hedge?
@rmackay9 there is also a small bug that i fixed today. a PR should be coming up soon-ish!
1 Like