I dont like the way guided mode is implemented!

[Angus Laurie-Pile]

I have been getting to grips with arducopter code over Christmas, and have had a lot of fun doing so! However the way guided mode has been implemented seems firstly a bit mad and secondly a bit of a hack in terms of MAVLink messages.

Firstly whenever the code receives a guided waypoint it automatically changes to Guided mode, which means it causes a degree of panic from someone like me who was not expecting it! I think it should only fly to guided waypoint when the mode has been explicitly set by the operator.

Secondly it uses the 'current' field (if current == 2) in the 'mission item' msg to indicate its a guided waypoint instead of a normal one, which is ok but a bit hacky.

I propose to change it so when guided mode is selected it sets the guided waypoint to its current position (effectively loiter), then when it receives subsequent waypoints they are used as guided waypoints, atleast until a different mode is selected.

Happy to make the changes, but would like everyone's opinion.

[Randy Mackay]

 

     I agree that it’s slightly mad to make the message to send a guided point is just the same as a regular point except for the current field.  We should probably have a special mavlink message to say ‘go to here’…maybe there already is one, I’m not really sure.   https://pixhawk.ethz.ch/mavlink/

 

     ..as for immediately switching to Guided mode automatically, I don’t think that’s particularly bad.  We already accept flight mode changes from the ground station so the alternative of forcing the ground station to send two commands instead of one doesn’t seem to make anything better if you ask me.

 

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Angus Laurie-Pile]

Fair enough. Any reason why we could not use the 'MAV_CMD_OVERRIDE_GOTO' msg?

Also, on the same topic I dont understand why if have the specific alt change only logic when current==3, as we have a MAVLink msg called MAV_CMD_CONDITION_CHANGE_ALT  which we use?

Gus

[Meier Lorenz]

Hi Angus,

I’ve highlighted already a while back that there is no need for a hack, since there was always a proper message for it. This one is the one which should be used:

https://pixhawk.ethz.ch/mavlink/#SET_GLOBAL_POSITION_SETPOINT_INT

Enjoy!

-Lorenz

------------------------------------------------------
Lorenz Meier
Computer Vision and Geometry Group
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

Am 03.01.2014 um 11:21 schrieb Randy Mackay <rmac...@yahoo.com<mailto:rmac...@yahoo.com>>:


I agree that it’s slightly mad to make the message to send a guided point is just the same as a regular point except for the current field. We should probably have a special mavlink message to say ‘go to here’…maybe there already is one, I’m not really sure. https://pixhawk.ethz.ch/mavlink/

..as for immediately switching to Guided mode automatically, I don’t think that’s particularly bad. We already accept flight mode changes from the ground station so the alternative of forcing the ground station to send two commands instead of one doesn’t seem to make anything better if you ask me.

-Randy

From: drones-...@googlegroups.com<mailto:drones-...@googlegroups.com> [mailto:drones-...@googlegroups.com] On Behalf Of Angus Laurie-Pile
Sent: January 3, 2014 7:11 PM
To: drones-...@googlegroups.com<mailto:drones-...@googlegroups.com>
Subject: [drones-discuss] I dont like the way guided mode is implemented!

I have been getting to grips with arducopter code over Christmas, and have had a lot of fun doing so! However the way guided mode has been implemented seems firstly a bit mad and secondly a bit of a hack in terms of MAVLink messages.

Firstly whenever the code receives a guided waypoint it automatically changes to Guided mode, which means it causes a degree of panic from someone like me who was not expecting it! I think it should only fly to guided waypoint when the mode has been explicitly set by the operator.

Secondly it uses the 'current' field (if current == 2) in the 'mission item' msg to indicate its a guided waypoint instead of a normal one, which is ok but a bit hacky.

I propose to change it so when guided mode is selected it sets the guided waypoint to its current position (effectively loiter), then when it receives subsequent waypoints they are used as guided waypoints, atleast until a different mode is selected.

Happy to make the changes, but would like everyone's opinion.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email todrones-discu...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[Meier Lorenz]

Hi Angus,

Right, that would be the other valid alternative and probably closer to the intent here - as it couples command and execution, which I think is what the current interface does.

So that would be COMMAND_LONG + the command and fields from MAV_CMD_OVERRIDE_GOTO

The benefit over using the setpoint would that this already takes the correct data path for commands.

-Lorenz

------------------------------------------------------
Lorenz Meier
Computer Vision and Geometry Group
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Angus Laurie-Pile]

Hi Lorenz

I will create an issue, implement, then create a pull request. Only thing is firstly what is the best way of letting all the different GCS developers know of the change (I will keep the old code in for backward compatibility, with some comments)

Secondly I am just a little confused as to when to use COMMAND_LONG instead of MISSION_ITEM, and vice versa?

Cheers

Angus

> To unsubscribe from this group and stop receiving emails from it, send an email todrones-discu...@googlegroups.com<mailto:drones-discuss+unsubscribe@googlegroups.com>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss+unsubscribe@googlegroups.com>.

[Meier Lorenz]

Angus,

Both COMMAND_LONG and full missions use the same command set. Not all commands make sense as a single command, but a relevant subset makes sense in both contexts, which is why they share the same basic description.

-Lorenz

------------------------------------------------------
Lorenz Meier
Computer Vision and Geometry Group
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

Am 03.01.2014 um 15:20 schrieb Angus Laurie-Pile <angusla...@gmail.com<mailto:angusla...@gmail.com>>:

Hi Lorenz

I will create an issue, implement, then create a pull request. Only thing is firstly what is the best way of letting all the different GCS developers know of the change (I will keep the old code in for backward compatibility, with some comments)

Secondly I am just a little confused as to when to use COMMAND_LONG instead of MISSION_ITEM, and vice versa?

Cheers

Angus

On Friday, 3 January 2014 11:33:13 UTC, Lorenz Meier wrote:
Hi Angus,

Right, that would be the other valid alternative and probably closer to the intent here - as it couples command and execution, which I think is what the current interface does.

So that would be COMMAND_LONG + the command and fields from MAV_CMD_OVERRIDE_GOTO

The benefit over using the setpoint would that this already takes the correct data path for commands.

-Lorenz

------------------------------------------------------
Lorenz Meier
Computer Vision and Geometry Group
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

Am 03.01.2014 um 11:38 schrieb Meier Lorenz <l...@inf.ethz.ch<http://inf.ethz.ch/>>:

> Hi Angus,
>
> I’ve highlighted already a while back that there is no need for a hack, since there was always a proper message for it. This one is the one which should be used:
>
> https://pixhawk.ethz.ch/mavlink/#SET_GLOBAL_POSITION_SETPOINT_INT
>
> Enjoy!
>
> -Lorenz
>
> ------------------------------------------------------
> Lorenz Meier
> Computer Vision and Geometry Group
> Institute for Visual Computing
> ETH Zurich
> http://www.inf.ethz.ch/personal/lomeier/
>

> Am 03.01.2014 um 11:21 schrieb Randy Mackay <rmac...@yahoo.com<http://yahoo.com/><mailto:<mailto:rmac...@yahoo.com>rma<mailto:rmac...@yahoo.com>ck...@yahoo.com<mailto:rmac...@yahoo.com>>>:
>
>
> I agree that it’s slightly mad to make the message to send a guided point is just the same as a regular point except for the current field. We should probably have a special mavlink message to say ‘go to here’…maybe there already is one, I’m not really sure. https://pixhawk.ethz.ch/mavlink/
>
> ..as for immediately switching to Guided mode automatically, I don’t think that’s particularly bad. We already accept flight mode changes from the ground station so the alternative of forcing the ground station to send two commands instead of one doesn’t seem to make anything better if you ask me.
>
> -Randy
>

> From: drones-...@googlegroups.<http://googlegroups.com/>com<http://googlegroups.com/><mailto:drones-...@googlegroups.com<http://googlegroups.com/>> [mailto:drones-...@googlegroups.com<http://googlegroups.com/>] On Behalf Of Angus Laurie-Pile
> Sent: January 3, 2014 7:11 PM
> To: drones-...@googlegroups.<http://googlegroups.com/>com<http://googlegroups.com/><mailto:drones-...@googlegroups.com<http://googlegroups.com/>>
> Subject: [drones-discuss] I dont like the way guided mode is implemented!
>
> I have been getting to grips with arducopter code over Christmas, and have had a lot of fun doing so! However the way guided mode has been implemented seems firstly a bit mad and secondly a bit of a hack in terms of MAVLink messages.
>
> Firstly whenever the code receives a guided waypoint it automatically changes to Guided mode, which means it causes a degree of panic from someone like me who was not expecting it! I think it should only fly to guided waypoint when the mode has been explicitly set by the operator.
>
> Secondly it uses the 'current' field (if current == 2) in the 'mission item' msg to indicate its a guided waypoint instead of a normal one, which is ok but a bit hacky.
>
> I propose to change it so when guided mode is selected it sets the guided waypoint to its current position (effectively loiter), then when it receives subsequent waypoints they are used as guided waypoints, atleast until a different mode is selected.
>
> Happy to make the changes, but would like everyone's opinion.
> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email todrones-discu...@googlegroups.com<http://googlegroups.com/><mailto:<mailto:drones-discus...@googlegroups.com>drones<mailto:drones-discus...@googlegroups.com>-discuss+unsubscribe@<mailto:drones-discus...@googlegroups.com>googlegroups.com<mailto:drones-discus...@googlegroups.com>>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<http://googlegroups.com/><mailto:<mailto:drones-discus...@googlegroups.com>drones<mailto:drones-discus...@googlegroups.com>-discuss+unsubscribe@<mailto:drones-discus...@googlegroups.com>googlegroups.com<mailto:drones-discus...@googlegroups.com>>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<http://googlegroups.com/>.

> For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[Kevin Hester]

I think this change is a good idea (and easy for folks to plop into the GCSen).  But yep, good to leave the old stuff in for a while: Users seem to use old vehicle sw loads for a number of months after a new build is released - the gcses will need to change later or conditionalize behavior based on the recently added feature of APM version codes sent down via mavlink.

[TedP]

I see this is an old thread, but am wondering if there is any movement on the request? My specific motivation is to explicitly require a mode change to GUIDED even at the expense of an extra command. The issue with me is that we have an on-board computer that auto-generates the next destination for our vehicle. However, if for whatever reason the APM goes into RTL, our computer will still continue to send destinations and will take the APM out of RTL mode and put it into guided. We are going to try to put in logic to detect the current APM mode before sending new destinations from our computer, but it seems kludgy (and susceptible to race conditions).

[Bill Bonney]

Have you tested this, since AFAIU, you need to set guided mode before you can send a guided mode WP. The featue was implemented as requested.

Bill

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Randy Mackay]

 

     Yes I think Bill’s right.  I had a peek at the code and it looks like the vehicle needs to be first switched to Guided before it will accept the position or velocity requests from the companion computer or GCS.

 

     I agree with TedP’s assessment that using the “current” field of the mission-item to designate the mission-item as a guided mode command is a hack.  This happened before Tridge and I joined the project but I’m pretty sure it stemmed from a misunderstanding of the MAVLink protocol.  The misunderstanding being that the “current” field is meant to indicate that the mission-item is the command that is currently being executed, not that the mission-item should be executed immediately (i.e. currently).  We should remove support for accepting mission-items as commands and instead ask all the GCSs to send a command-long which contains the command.

    If TedP or someone else wants to take-on making this change we’d very much welcome the Pull Request.

 

 

-Randy

[TedP]

Hi Bill and Randy: Thanks for the feedback. I just did a first pass scan of our on-board code, and it seems we ONLY send MISSION_ITEM commands to discipline our vehicle. I will do some additional checking to confirm this (including going through the APM logfiles), but perhaps we are running an older version of APM? Is there any documentation to tell us which version the change was implemented so we can confirm.

Randy: We would be happy to contribute to the project. Right now we're heads down trying to prepare a demo, but in the very near future we should be able to have some bandwidth. My presumption is that Guided mode would listen for "COMMAND_INT" from the GC (or alternate source) to discipline its' course?

-Ted