Closed DonLakeFlyer closed 7 years ago
I can't speak to the inner workings of the code, but as a user of many ground stations over the years I've seen the following behavior is typical. Actually, this may be more of an autopilot thing than a ground station thing although the two obviously work together:
Typically the autopilot has a current waypoint it is tracking to. When it receives a new mission the autopilot keeps the same active waypoint index and it just goes to that new location. I suppose the GCS could be listening to the current waypoint from the autopilot and set that index as active when the new mission is sent - not sure what side of the fence is most logical.
There needs to be safety logic about not going to the new waypoint if it is not a normal waypoint (e.g. do not go to it if it is part of a landing pattern, or takeoff pattern, some special action, or something else that isn't a normal waypoint/loiter point).
for systems that can store more than one mission on board, it is important to prevent the autopilot from jumping to that waypoint index in another mission. This may also apply if there can be multiple closed circuits in a single mission file.
If the previously active waypoint index is no longer in the mission or is rejected for the above reasons I've seen it handled multiple ways: a) loiter in place until the user commands a new active waypoint, b) start over at the beginning of the mission or circuit. or c) find the nearest normal waypoint to the vehicle's current location and go there.
another approach useful in survey type patterns is to search for a waypoint in the new mission that has the same lat/long/alt as the previously tracked waypoint on the autopilot and switch to that in the new mission. This is useful to not interupt the survey pattern.
A lot of that would need to exist on the firmware side (which I'm happy to help with).
Correct me if I'm way off here, but if we first had a solid mechanism for ensuring GCS and autopilot mission were in sync would it make the more advanced features feasible?
It's more complicated that just that. At the beginning of a mission (or in the middle even) there can be various camera setup commands like setting up the distance trigger for example.If you want to resume a survey you need to restart the camera as well or you'll fly the pattern but take no images.
So you actually need to regenerate the mission, pulling all the DO commands off the front up to the point where you want to resume and then add the rest of the mission. Then send the new mission to the vehicle. Then you need to think about what you do with taking off for the resumed mission. Do you have to manually take off? Or do you also magically pull the takeoff sequence from the front and stuff that back in as well. It's get crazy pretty fast.
More problems: If you RTL to swap batteries on a fixed wing, won't it just go the DO_LAND_START which in turn will trash your mission current item to go back to?
I just tried an RTL in SITL from the middle of the mission. When the vehicle landed vehicle reset current mission item to 0.
I didn't realize this was about landing mid-survey mission and resuming. I was mainly thinking of the case where you're currently flying a mission and want to tweak a waypoint mid-flight.
I know this isn't immediately helpful, but I was thinking many of the survey issues could go away if the autopilot actually had an understanding of what it was doing instead of just dumbly executing a command sequence. That could mean either a single mission item that outlines the polygon (the autopilot is now responsible for calculating the grid), simply marking the start and end of a survey sequence, or just having individual trigger commands throughout.
The point is to be able to do a battery change in the middle of a mission and then keep going.
Ah, some topic confusion on my part too. I'd argue good behavior with updating a mission in flight is a more fundamental capability than mission resume (i.e. everyone would expect a UAV to be able to do that). However, mission resume is a really good feature for surveys and I am excited about the capability. Are there discussions elsewhere that describe the intended functionality?
The different ways Fixed Wing and VTOL handle takeoff and landing could make certain approaches to resume problematic. Are you depending on the autopilot to remember where it left off or is QGC going to remember where it left off and send the vehicle there at the appropriate time?
I don't really know how this is intended to work, but this is how I'm brainstorming about it:
@DonLakeFlyer have you considered surveying with one waypoint + DO_DIGICAM_CONTROL placed at each desired image location? With that type of survey mission QGC could pause the mission (save current index + RTL), then use MAV_CMD_MISSION_START (specify start index) to resume. MC and VTOL handle the takeoff properly without a takeoff waypoint. FW doesn't really, but could with a little thought.
I have it all figured out. I'll explain soon.
Ok, here is how it works:
Not done:
The list of commands which are looked for to get re-added at the beginning of the mission are:
Here is the visual sequence, using a Survey as an example:
Plan a Survey:
Fly the Survey:
RTL from middle of Survey:
After battery swap and reconnect, click Resume Mission:
Confirm resume mission:
Confirm changed mission:
have you considered surveying with one waypoint + DO_DIGICAM_CONTROL placed at each desired image location?
You can't do that because it blows up the mission item count like crazy on large surveys and can exceed the mission space available on the vehicle.
For fixed wing I think it comes down to being the operators job to get the vehicle back up into the air. And then they can resume. The guided bar is not yet set up for that but I will fix as I finish fleshing this out.
For fixed wing I think it comes down to being the operators job to get the vehicle back up into the air. And then they can resume. The guided bar is not yet set up for that but I will fix as I finish fleshing this out.
An option for that is to ignore everything past MAV_CMD_DO_LAND_START since that can be considered part of the landing approach. The mission logic then just needs to manage the jump from FW takeoff to resume_seq_no instead of the waypoint following takeoff.
The current PX4 nuttx (pixhawk) mission limit is 2000 commands, and UINT16 on other platforms.
On Thu, Mar 30, 2017 at 1:15 PM, Don Gagne notifications@github.com wrote:
have you considered surveying with one waypoint + DO_DIGICAM_CONTROL placed at each desired image location?
You can't do that because it blows up the mission item count like crazy on large surveys and can exceed the mission space available on the vehicle.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mavlink/qgroundcontrol/issues/4883#issuecomment-290479118, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFK6OoDk3MWCs7yvfwzcbu4DpqLqgCDks5rq-MhgaJpZM4MtPl4 .
The current PX4 nuttx (pixhawk) mission limit is 2000 commands,
If only my life were as simple as to only need to run on a single firmware type :)
An option for that is to ignore everything past MAV_CMD_DO_LAND_START since that can be considered part of the landing approach.
MAV_CMD_DO_LAND_START ? I don't get it. To me the only way to pull a correct takeoff sequence from the beginning of mission would be if there was some sort of MAV_CMD_DO_TAKEOFF_STOP marker.
To be honest this feels like we're fighting a bad abstraction, but I'll try to be productive.
What if the first time you create the survey you have a NOP jump at the beginning (just after the camera setup). At pause you store the current index to update the jump (could be immediate, or when you click "Resume Mission (9)") and then you RTL. After replacing the battery you simply start the mission again. Same takeoff, same camera setup, jump to where you left off and continue.
Camera commands can be anywhere in the mission not just at the beginning. With waypoint interspersed in between.
To be honest this feels like we're fighting a bad abstraction
Tell me something I don't know.
The current PX4 nuttx (pixhawk) mission limit is 2000 commands, and UINT16 on other platforms.
We often fly survey type missions with many more than 2000 photo points.
This is all working. But I'm not very happy with the requirement to not disconnect from the vehicle. Looking into how to not require that.
Going to live with no disconnecting for 3.2
Discussion starts in #4868. Rest of discussion should be here.