SET_POSITION_TARGET_GLOBAL_INT velocity bound by WPNAV_SPEED

ArduCopter Copter 4.1
,
1

After the latest beta update (4.1.0 beta in SITL), the target velocity can no longer override the WPNAV_SPEED_UP and DN.
This is problematic because then the same parameter is used both for target navigation and for TAKEOFF/LAND commands.
Meaning, if I want to be able to command the drone to fly up to 5m/s upwards, it will also ascend at 5m/s during takeoff. Same for descent and landing - I may want to be able to give a setpoint of 3m/s downwards (especially if the other velocity components are non-zero), but landing at that speed is not very graceful nor safe.

2

What do you mean with the latest beta? Is it beta5 or is it beta 6?

Please update to beta6 if fixes guided issues.

3

@amilcarlucas I’m struggling to get the exact version from the SITL (QGC only says 4.1.0dev), but I did git pull less than 30 mins ago and it is still bound by WPNAV_SPEED.

4

@Pokornz,

Thanks for the report

When you say, “the target velocity” I guess the vehicle is in Guided mode and you’re sending it SET_POSITION_TARGET messages with the velocity fields filled in and finding that it doesn’t go faster than WPNAV_SPEED_UP or DN?

… or maybe the vehicle is in Auto mode and the DO_CHANGE_SPEED command isn’t taking effect?

If you’ve got a log demonstrating the problem that would be great. Thanks very much for the testing and report.

5

@rmackay9
It is as you’re describing in the first paragraph.

As indicated in the topic title, I’m using SET_POSITION_TARGET_GLOBAL_INT messages. Both position and velocity fields are filled (and ignore bitmask is set accordingly).

I’m not sure if the last version where I was able to go above the WPNAV_SPEED limits was beta4 or beta5. Is there a way to see the exact version in SITL? QGC only says 4.1.0dev no matter the beta number.

6

If QGC says 4.1.0dev, you are not using any of the betas.

QGC will say 4.1.0-beta4 or 4.1.0-beta5 when you use the beta releases.

7

@Pokornz,

OK, thanks for the clarification.

@Leonardthall and I discussed this limitation as we reworked guided mode (code is here) so it was a conscious choice to apply the limits from Auto to Guided mode… I’ll have a chat with Leonard about what we can do. Some ideas are:

  1. Add a bit to GUID_OPTIONS to allow bypassing the WPNAV_ limits when doing velocity control
  2. Always allow the velocity controller to bypass the limits (this might have been the old behaviour)
  3. add TKOFF_SPEED parameters to allow specifying takeoff altitude
  4. add GUID_SPEED_ parameters to allow specifying guided mode limits (but not apply them to the takeoff somehow)
1 Like
8

@amilcarlucas
I’m pulling from straight from the ardupilot repo.

git remote --verbose
origin	https://github.com/ArduPilot/ardupilot.git (fetch)
origin	https://github.com/ArduPilot/ardupilot.git (push)

Maybe I should switch from master branch to Copter-4.1 branch?

1 Like
9

@rmackay9
I think it depends on what you want the philosophy of guided mode to be. If it should be a direct “developer level” access where it is the responsibility of the developer to limit the target velocities before sending them, or whether it should still have safeguards for less experienced users and can only be overridden as a conscious choice.

2 Likes
10

Yes, by using the Copter-4.1 branch you will get the somewhat stable beta versions.

1 Like
11

@Pokornz,

Yes, that’s a good summary of the decision. @Leonardthall and I discussed this morning and we’re going to try and remove the limits on the velocity and acceleration inputs.

1 Like
12

@amilcarlucas
The sim_vehicle.py failed to build the Copter-4.1 branch. Should I make another topic about it or should I wait till another release?

13

Make another topic, its another subject

14

I think this is summary does not appreciate complexities of producing smooth high rate position controller commands from low rate guided commands. The new guided mode interface produces jerk limited kinematic paths that reliably reproduce low rate guided commands without large ugly discontinuities.

Previously you would need to hide these discontinuities with soft (ie poor) position controller gains or by relying on slow command inputs. By this I mean putting in position moving position targets rather than velocity targets.

The new guided mode design lets higher level users specify position, velocity AND acceleration to achieve much faster and more precise navigation that was not remotely possible previously.

To do this we must specify two types of limits, the correction limits and the absolute limits. On top of this the PID controllers need to be limited appropriately to ensure they do their job in harmony without overpowering our commands.

I need to think about this further…

1 Like
15

@Leonardthall
It’s great to hear that acceleration commands will be supported.
Just to give you some idea, I’m using guided mode for navigation along 3D circle-like curves and update the posvel commands at 100Hz.

16

If you specify the lateral acceleration of the curves your are generating you will find you get much smaller discontinuities in your path and therefore smaller twitches.

You may also benefit from reducing the variable PSC_TC_XY to 0.5.

17

@rmackay9

… or maybe the vehicle is in Auto mode and the DO_CHANGE_SPEED command isn’t taking effect?

This is exacly the problem i’m having on 4.1.1 rc1, can you check here please