Considering the fact that we’re mowing our lawns with firmware initially designed to fly copters, I’m sure there’s plenty that’s not been considered! Thank you and the team so much for the attention you’re giving this niche use case!
5 Likes
I also continually get “Unhealthy GPS Signal” only when using GPS_DRV_OPTIONS=0. I do not get the issue with the UART2 crossover physical connection. Same type of system components as Yuri. Thanks for your excellent work here - I now have fully automated mowing on my farm.
5 Likes
I only got sporadic “Unhealthy GPS Signal” warnings with GPS_DRV_OPTIONS=0. However, I’m using a Cube Orange with a very fast processor by comparison to other flight controller boards. Perhaps with a slower processor, the flight controller simply cannot process the RTCM3 messages fast enough.
It’s when I set GPS_AUTO_CONFIG=0 that I get persistent “Unhealthy GPS Signal” messages.
In @ktrussell’s latest video where he uses an external source for RTMC3 corrections, there is also the same message after it appears benchtop Pixhawk is fully aligned with a good GPS2_RAW.yaw solution (GPS_AUTO_CONFIG=0 in that example, also).
There’s an additional interesting observation in that video - it seems like configuration messages are sent from the flight controller to the F9Ps in an endless cycle, not just at boot time. He says that if GPS_AUTO_CONFIG is enabled, he cannot use uCenter to change the settings because “they just change back.”
1 Like
I think AP should be configuring the F9 optimally for use with AP so I wonder why uCenter is ever required. I think the “unhealthy GPS signals” are probably an indication that the GPS hasn’t been configured properly which makes sense if GPS_AUTO_CONFIG = 0.
I haven’t used GPS-for-yaw yet but I would hope that if setup according to the wiki that there shouldn’t be any need to use uCenter to re-configure the GPSs or make any changes that aren’t mentioned on the wiki.
I’ve added a bunch of items to the Rover-4.1 issues list but I think I’d better watch Kenny’s video and maybe I’ll better understand the issues.
Randy, AP auto configure assumes that the moving base receives RTCM3 via the flight controller/MAVLink injection on UART1, which is the most likely case. @ktrussell uses an external source for RTCM3 injects to the moving base on UART2, therefore uCenter is required, and auto configuration by AP is not desirable (or auto configuration should have multiple options).
In my case, auto configuration is indeed desirable, but I’m confused as to why it needs to happen on every boot cycle. It seems to me that one boot cycle with GPS_AUTO_CONFIG=1 and GPS_SAVE_CFG=1 should be adequate. Thereafter, the F9Ps should retain the optimal configuration, thus saving some time during the boot sequence as well as possibly saving some EEPROM write cycles on the expensive chips (though GPS_SAVE_CFG can be disabled with no ill effects, so the latter point may be moot).
Again, it’s an extremely minor inconvenience to wait for the configuration routine on each boot, and I can live with that.
Thanks for the feedback and suggestions. I’ll discuss with @tridge.
A couple of questions:
- how do you know that AP is updating the GPS configuration when it is not necessary? My guess is that it checks the configuration at startup and then if any values are different it sets them but I could be wrong.
- what is the advantage of directly connecting the GPSs together using a uart cable instead of going through the autopilot? I’m just wondering why we would want to support two different configurations like this.
-
Check out Kenny’s video. He’s got uCenter connected while using the flight controller, and his observation was that anything he did in uCenter was immediately changed back to the auto configuration setting. @ktrussell would probably be better suited to discuss further.
-
Directly connecting the GPS modules avoids latency in RTCM3 message traffic (and presumably frees flight controller processor time). It’s highly desirable, I think, and is the reason for GPS_DRV_OPTIONS=1. I can’t think of a disadvantage to the rover receiving RTCM3 injects directly from the moving base via UART2.
Unfortunately, I did not demonstrate the overwriting of the config if auto config is turned on. I mention it at this point: https://youtu.be/A1QbHG6SBUk?t=261. I can easily hook back up and demonstrate if it will be helpful.
I agree with Yuri on the external comm being a desire. And it is almost there. The only changes I feel that are necessary is to:
- Create a parameter that specifies the desired baud rate between the 2 GPSes and then have Ardupilot autoconfig set that.
- Enable RTCM3-IN on UART2 for both GPSes. This lets us have (a) RTCM3 for the Moving Base come from an external source if we desire and (2) lets RTCM3 go from Moving Base to Rover externally (this is already supported if GPS_DRV_OPTIONS=1).
Note that it is OK in the F9P to have both UART1 and UART2 on the GPSes set to allow RTCM3 IN. The GPS will take the RTCM3 stream from whichever port is receiving it. So the settings I suggest in 2, can be done whether GPS_DRV_OPTIONS is 1 or 0.
I would say that enabling RTCM3 OUT on the Moving Base UART2 would be best only if GPS_DRV_OPTIONS = 1, so that the GPS isn’t using its resources to pump out data to UART2 if it is instead sending via UART1 through the flight controller.
2 Likes
@rmackay9 @Yuri_Rage, I couldn’t help myself. Everything was still hooked up, so for what it’s worth, I created a video to demonstrate: https://youtu.be/5U5_OwFCw3o
1 Like
Perfect demo! Thanks for uploading that.
You’re providing some motivation for me to create an overview video much like the previous one where you describe your wiring and architecture - great format (I’m gonna borrow it…).
3 Likes
I had a reasonably long discussion with @tridge yesterday regarding the struggles getting GPS-for-Yaw working. I was surprised by all the pitfalls that users can fall into. The setup is clearly better than 4.0 but far from easy.
One of the biggest issues is the high bandwidth means DMA is required on the serial connections to the GPSs but it is difficult for users to know which serial ports are using DMA.
Another issue is AP forces the baud rate to 460,000 (or whatever) which you’ve pointed out.
We also have no wiki instructions (I think) on how to setup GPS-for-yaw by directly connecting the GPSs to each other. FYI @hwurzburg.
There are a number of things we can do to make this better:
- Allow users to set the baud rate to whatever is held in SERIALx_BAUD. I think @tridge is planning to add a bit to GPS_DRV_OPTIONS.
- Document the GPS-to-GPS setup method
- Document how users can determine which serial ports have DMA available
- Support GPS-for-yaw using two CAN GPSs. If we use CAN the messages from the base to the rover will still physically travel through the autopilot but the autopilot won’t need to read or touch them so no CPU cost.
Thanks again for your dedication to setting this up and providing great feedback!
P.S. we’ve just merged PR 16550 which may mean that if you use “latest” the baud rate will be set at 230400 (instead of 460800) in some cases. Sorry, I don’t fully understand everything but I thought a warning might help if you see something weird when you next update your firmware.
@rmackay9, @Yuri_Rage
Thanks for the good news about the conversation with @tridge. I am excited at the possibility of a few small changes making it work great.
I did not know about the DMA being on some ports and not others, nor that CAN is handled outside the processor.
If there are questions I can answer to help with the documentation, I certainly am happy to help. I may be able to write up some notes to assist.
1 Like
@rmackay9 , @ktrussell
Awesome! I’m looking forward to testing the new builds as they happen, and I’ll continue to provide feedback as much as I can. It’s really encouraging that the project is moving forward so quickly.
I was also unaware of the DMA issues, which helps shed light on how difficult your task can be at times. Makes perfect sense to support CAN GPSs for GPS-for-yaw.
I love the idea of adding a bitmask to GPS_DRV_OPTIONS for various configurations. I was hoping that would happen…and maybe I should’ve just requested it outright.
Thanks for the warning about baud rate changes, as well - that would’ve knocked me for a loop for a bit.
1 Like
Hey Yuri! I just want to say you’re getting me interested in picking up this project again. I was picking Kenny’s brain last year, and when I started shopping for a sacrificial mower, I found a boat project which blew my budget. With that finished last week, I’ve been bookmarking and digesting everything you’re doing on GitHub and ardupilot.
My intention is to approach and document this from a zero-to-hero perspective. I have only light familiarity with coding/dev, so I’m in a great position to be able to make this more user friendly.
Anyways, just wanted to say hi. If you’re willing to exchange emails with me, mine is just my username at Gmail.
-Shale
1 Like
Thanks for the intro and your interest in documentation! In my experience so far, the AP project moves so fast that the online documentation has no choice but to lag development (sometimes significantly), which is an unfortunate and often frustrating reality.
If you’re cataloging helpful links, don’t forget about the trove of info on YouTube, in particular:
https://www.youtube.com/user/AndrewTridgell
https://www.youtube.com/user/rmackay9
https://www.youtube.com/c/KennyTrussell
(and my own channel)
I’d prefer to keep the dialog here, either in the public forums or via private messaging. I’ll try and keep up as best I can here!
3 Likes
I updated to 4.1.0-beta3 today with no issues other than an odd Mission Planner crash when I first connected to the newly updated flight controller. An update of MP to its own beta version fixed that.
Most of the release note fixes were either not noticeable or not applicable, but I am successfully mowing the lawn with the new firmware as I type this.
I know some updates were made to the GPS-for-yaw logic, but I noticed no changes other than the use of the 230400 baud rate in place of 460800. I still must use GPS_AUTO_CONFIG=1 to eliminate what appear to be nuisance ‘Unhealthy GPS Signal’ messages even after saving the uBlox settings and rebooting with GPS_AUTO_CONFIG=0. When I get some time, I’ll connect uCenter and compare settings in both cases.
Unrelated to the beta update, I did prove to myself today that fence radii must be integer values. You can set/save decimal values in Mission Planner, but they are truncated to integers when uploaded to the flight controller. It’s of little consequence, really. A ¬6’ diameter exclusion zone (1m radius) around trees works very well for my use case.
2 Likes
Hi @Yuri_Rage,
Thanks forgiving -beta3 a try and reporting back.
Re MP crashing a good number of users (including me) have experienced this and I’ve sent @meee1 some screenshots, videos and error messages and I’m sure he’s looking into it. It seems likely that it’s related to the parameter download via MAVFTP.
Re GPS-for-yaw, we haven’t made any improvements (yet) except the one you’ve noticed re the baud rate but I expect we will in an upcoming beta (maybe -beta5).
Re the fence radius, do you mean the “FENCE_RADIUS” parameter? I tried changing this to 300.1m and it seems to work ok. If you can give me some details about which parameter or how you’re setting it I may be able to figure out what’s going on.
As a side note, I’ve found that the “WP Radius” field on the Plan screen doesn’t seem to work so I’ve raised an issue with MP.
1 Like
Randy, no, not the FENCE_RADIUS parameter, but rather individual circular exclusion fences. Mission Planner will allow decimal values as shown below, however once uploaded, it appears they are truncated to integer values. If I upload the fences as shown, then use the “Read” button to download them again, they will all show 1m instead of 1.5.
In practice, I tried uploading 1.5m fences and 1m fences, and I noticed no difference in behavior/path, so I think I proved the hypothesis.
However, I don’t see this as a significant issue unless it’s not desired behavior.
I’ve not yet had a problem setting WP_RADIUS in the MP planner (although it will display horrifically long decimal values if one chooses to use feet instead of meters as the MP default unit). However, I rarely change that value, so perhaps what you experienced is a newly introduced bug.
1 Like
@peterbarker has tracked down the problem with the Fence Radius being truncated and we have a potential fix but it may mean we need to wipe everyone’s existing fences as part of the upgrade to 4.1 so we need to discuss this first. Thanks again for noticing this.
1 Like