I’m having a bit of trouble getting indoor localization to work using the MM 4.9 beacons with Rover 3.4.1-rc1. For starters, I’ve been testing with a simple mission that has the rover drive in a straight line, but I have yet to successfully reach the waypoint.
Using the instructions found here: http://ardupilot.org/rover/docs/common-marvelmind.html, I cannot seem to get a decent position lock. The location moves around wildly and the EKF3 module resets itself every couple seconds.
I’ve had more success with using an older guide from MM: https://www.marvelmind.com/downloads/marvelmind_pixhawk_v2016_10_11x.pdf. Here, the hedgehog outputs data using the NMEA protocol and is treated as GPS information by APMrover2. This has given me adequate localization information, but I’m running into difficulty with compass headings. Even after correctly orienting the compass in the MM dashboard, the rover seems to always seems to settle into a heading about 60-90 degrees off from correct. When I first calibrate the compass, everything looks lined up, but then there is typically a yaw error and suddenly, things are pointed off in the wrong direction.
If I disable the compasses, then the heading remains much more true after a bit of manual driving; however, when executing the missing with a waypoint directly in front of the rover, it veers off to the right, missing the point by a large margin.
I’d appreciate any thoughts or suggestions on either of the above approaches. It appears that others have been quite successful, but I can’t seem to replicate those results. Thanks!
After some outdoor testing with GPS, I’m beginning to suspect that the underlying issue is not related to the Marvlemind system. Instead, there seem to be issues with tuning (?) that’s causing the rover to drive circuitous routes.
Here is a quick video I took to show off the issue I’m observing: https://youtu.be/ADvvmU8at2Q. I have a fairly simple mission: one waypoint in the middle of the far end of the parking lot and then a second near the center. From past experience with ardurover, I would expect the rover to drive in a straight line to the first waypoint, turn, and drive in a straight line to the second waypoint.
Instead, you will notice that the rover initially turns to drive in the incorrect direction and then drives in a sweeping sine curve to the waypoints. Previously, I was observing the rapid oscillation seen at the beginning of the video for the duration of the mission, but I was able to dampen this to the sweeping curves following this guide: http://ardupilot.org/rover/docs/rover-tuning-navigation.html. I should also probably note here that I have to cruise speed and throttle parameters set to be approximately 1 and 10, respectively, to slow the rover down to a manageable speed; I’m not sure if this could be wreaking havoc on the navigation.
I feel as though I might be missing something obvious in terms of tuning or rover configuration. Do you have any pointers on where to go from here with adjusting parameters?
Thanks for the video, control problems I can help with!
Before tuning navigation, it’s important to get the speed/throttle tuning and steering rate tuning right. This is because the navigation controls are built on top of these two lower level controllers. If the lower level controls aren’t performing well, the upper level navigation control won’t either.
There are videos at the bottom of each page as well to show how it’s done.
For speed/throttle, the easiest way is to temporarily setup a channel 7 switch to capture the cruise-speed and cruise-throttle. By the way, to slow down a mission, it’s actually best to changer wp-speed instead of cruise-speed.
For steering rate control tuning, the ATC_STR_RAT_FF parameter is the most important. If this parameter is close to the right value, it should work.
Dataflash logs will also show whether it’s an estimation problem (i.e. something wrong with the marvelmind setup) or a control problem (i.e. tuning)… so if you have one I can have a peek.