QGC 4.0.1 (android 7.1)
I was unable to publish missions to my 3DR Solo running ArduCopter 4.0.3 and OpenSolo 4.0.0 using QGC 4.0.1.
Is this limitation known/expected, or an oversight on my part?
Thanks,
Brett
It should work. What does unable mean. What sort of error are you getting.
1 Like
I need to re-try later and pull logs from the console on the Android device, but something to the effect of unable to transfer mission, exceeded number of retry attempts.
This is while connected and getting telemetry from my Solo, so I know that at the very least MavLink was communicating to QGC.
Turn on PlanManagerLog save console output. And put that into an issue.
That usually means really noisy connection.
1 Like
Also take a look at mavlink loss rate from Settings/Mavlink page.
1 Like
Turned it on. Is this setting “sticky” across app reboots?
I would be highly surprised given that Tower and Solex worked just fine in the same conditions and neither warned of a bad connection (standing 3ft away from the sUAS). I’ll take a look, however.
I’ll check that. Shouldn’t the plan/fly screen have thrown a warning if there was an issue with the mavlink connection?
I just saw/ticked the box for allowing the mavlink stream rates to be determined by the vehicle, which was not ticked this morning. I assume this is the safest setting for ArduCopter vehicles like the Solo, right?
This is for setting up for really slow telemetry. For regular use you shouldn’t use it.
1 Like
Artoo is fast enough to leave the QGC default Mavlink stream rates? Alright, I’ll turn that back off. Thanks for the heads up.
This usually indicates a bug in QGC with respect to a difference in ArduPilot handling of some specific mission command. Can you attach the plan file?
1 Like
From the Plan file I can see that they were created for PX4 firmware which supports the MAV_CMD_SET_CAMERA_MODE command which will get added to the start of mission that runs any of the Patterns. Whereas if the firmware is set to ArduPilot that command will not be added. And then ArduPilot has this strange code in it which checks for NaNs which doesn’t really work correctly for commands which are not supported. In reality ArduPilot should have reported command not supported.
If you want use the plans on ArduPilot you can manually edit them to remove the 530 MAV_CMD_SET_CAMERA_MODE command.
Anyway, things are working correctly here. You’ve just run into some of the quirks of the differences between PX4 and ArduPilot.
1 Like
How does one force ArduPilot support when planning, then? I can’t seem to change it from PX4, and I had no idea that (since the control was disabled) it would be so critical to my usage.
Does QGC allow for on-the-fly translation between PX4 and ArduPilot plans so I don’t have to completely remake my plans?
You can’t change the firmware/vehicle information in QGC once the plan is created. Hence it’s disabled. When you have no plan in the Plan view you can change the Vehicle Info setting. Normally this would be set automatically by first connecting to a vehicle which will set the defaults in QGC. You can fix this up manually by changing the firmwareType field in the file to 3 (https://mavlink.io/en/messages/common.html#MAV_AUTOPILOT).
As it currently stands PX4 and ArduPilot are not compatible enough with each other with respect to mission command support such that a Plan created for one firmware can run without problem on abother. The features they support differ and especially with Surveys the specifics of those differences matter enough to impact the ability to get a good survey.
2 Likes
Also just to continue it’s likely the firmware differences for generating patterns is going to diverge more. For example I am currently working on support for MAV_CMD_CONDITION_GATE. This allows for much more precise triggering of starting/stopping photo triggering right at the edges of the survey area. Using this allows you to not need need to specify “Images In Turnarounds” to make sure you are getting good coverage at the edges of your survy polygon.
This should show up in PX4 firmware soon. Not sure if ArduPilot will add support for it. There are already other missing things in ArduPilot as well which cause poor edge cover. For example support for MAV_CMD_DO_SET_CAM_TRIGG_DIST.trigger=1, which allows you to start distance based triggering with an initial image triggered right away. This allows you to catch the image right at survey edge entry.
So anyway, long complicated explanation. But shows some of the complexity of implementation a ground station which supports multiple firmware which don’t work alike.
The addition of CONDITION_GATE support will also likely trigger even more need in QGC to first ask the user at least once what firmware they are using if they have never connected a vehicle. Instead of dealing with it the way that works now, which as you can see has holes. That will show up at some point in the daily builds
3 Likes