But I think it is already the way you need it. But, I guess the issue is that you do not have the Moving Base connected to the Flight Controller at all, so ArduPilot can’t configure it at all. Bummer.
I flew the drone, and it was magnificent, much better without the compass, the unheatlhy gps is just an annoyance , but it can fly
1 Like
FYI Tridge has created a pull request that improves serial performance on some serial channels by using a FIFO. This should make setting up the GPS-for-yaw a little easier on CubeOrange and other high powered H7 boards when the autopilot is in the middle (e.g. GPSs are not directly attached together).
If anyone is willing to give it a try I’ll create a binary for CubeOrange or whatever board you’re using.
2 Likes
Sent you a message regarding the new build. I will definitely be up for testing next week. I can test both autopilot-in-the-middle (Cube Orange) and direct F9P-F9P communication over uBlox UART2 configurations with minimal effort to switch between the two. The only configurations I can’t test are the piggyback board setup that GRS26 uses and external (non-MAVLink) RTCM3 injection like Kenny does. I’ll let you know when I’m back up and running so we can coordinate the binary download.
1 Like
Looking at implementing the GPS Yaw since my magnetometer isn’t getting good readings on my large rover. Looks like everyone is having great success with it and have extremely accurate headings! Are you just using 2 F9P GPS units onboard the rover? Do you have to send RTCM3 correction data to one of the GPS units or can you just use the two onboard without corrections? I currently have a SparkFun Zed F9P paired with a Mrobotics Rev2 controller running ArduRover 4.0.
Moving baseline (GPS for yaw) does not require RTCM3 injection from an external source. However, your flight controller looks to be based upon a fairly old processor that may not support the feature set.
1 Like
Randy,
I can also test if you would like me to. I can test any of the configurations I suppose. I have never done MAVLink injection but I can connect that too if that is part of the test case needed. I’m running a Cube Orange now.
Kenny
2 Likes
How do you know which processors are supported?
Check this link out. I don’t know the exact specs of your board, but it may fall into this category.
https://ardupilot.org/copter/docs/common-limited-firmware.html
Great thanks for the heli. Here is the Rover-4.1.0-dev build including Tridge’s serial port “fifo” enhancement.
Hopefully you won’t notice any differences except perhaps the gps-for-yaw performance is more reliable when the autopilot is in the middle.
1 Like
So long as everything fires up today, I’ll be testing this shortly. Thanks Randy!
@rmackay9, I have successfully uploaded and booted the dev build you shared. I also updated Mission Planner, and it appears the vaporization problem is gone.
With the uBlox UART2 ports physically disconnected and no parameter changes except for GPS_DRV_OPTIONS=0, I have extremely intermittent GPS2_RAW.yaw (it mostly stays at 65535 but occasionally updates to a valid value). It is effectively unuseable as is.
I see a note from @tridge about setting SERIALn_OPTIONS to 768. I am using SERIAL3 and SERIAL4 as moving base and rover, respectively. I will try SERIAL4_OPTIONS=768 next.
2 Likes
I have tried the following configurations under Randy’s 10 Jul 2021 4.1.0-dev build:
- uBlox UART2 ports disconnected from one another
- GPS_DRV_OPTIONS=0
- SERIAL3_OPTIONS=0
- SERIAL4_OPTIONS=0
-
GPS yaw too intermittent to use
– - uBlox UART2 ports disconnected from one another
- GPS_DRV_OPTIONS=0
- SERIAL3_OPTIONS=0
- SERIAL4_OPTIONS=768
-
GPS yaw too intermittent to use
– - uBlox UART2 ports disconnected from one another
- GPS_DRV_OPTIONS=0
- SERIAL3_OPTIONS=768
- SERIAL4_OPTIONS=768
-
GPS yaw too intermittent to use
– - uBlox UART2 ports connected directly (crossover communication)
- GPS_DRV_OPTIONS=1
- SERIAL3_OPTIONS=768
- SERIAL4_OPTIONS=768
- GPS yaw rock solid
Of note: GPS_AUTO_CONFIG=1 is still a must to avoid nuisance “Unhealthy GPS Signal” messages.
Well that was certainly interesting! One of my steering arm brackets worked itself loose during the mowing session, causing the autopilot some significant control issues completely unrelated to the new build. Things were working great, and suddenly the mower was occasionally on Mr. Toad’s Wild Ride. Now that I know root cause, I’m actually surprised at how well the controller was able to maintain the mowing pattern with so little directional control!
1 Like
can you send me the log for this one?
Re the control arm problem, I have thought once or twice that we should add a control failsafe that checks the desired vs actual turn rates and acceleration. We have something similar on Copter and it would be optional of course so it could be disabled during tuning or situations where you really want the vehicle to keep trying instead of stopping.
2 Likes
Yes. I’ll reset to that config later today or tomorrow and get you a clean boot sequence and maybe 5 mins of runtime.
@rmackay9, that sounds like a really good fail safe. I’ve had a few instances where my either own stupidity or some unexpected failure has resulted in some pretty wild behavior that could likely have been detected and prevented in this way.
Thanks, Randy!
Requested .bin log sent.
Pro-tip for those reading - it’s WAY faster to download logs directly from the SD card rather than over a telemetry link. However, the Cube autopilots make that card quite difficult to reach. Add a little masking tape tab to the outside edge of the card for easy removal.
3 Likes
ahh, I see you’re running the GPS modules at 10Hz. That won’t work. Please set GPS_RATE_MS=200 and GPS_RATE_MS2=200.
At 10Hz there isn’t enough bandwidth. More than 5Hz is not an advantage anyway, as the EKF does a great job of interpolating between GPS samples. We are much better off with reliable 5Hz than unreliable 10Hz.
3 Likes