Add an example code for movement in GUIDED_NOGPS mode#712
Add an example code for movement in GUIDED_NOGPS mode#712studroid wants to merge 6 commits intodronekit:masterfrom
Conversation
squilter
left a comment
There was a problem hiding this comment.
Thanks for the work! I think it would be good if you could write a comment that is a bit more explicit about what the user should expect the vehicle to do. Given that the vehicle will be in Guided-NoGPS mode, a lot of unexpected behavior could occur. It would be helpful to warn anybody that might just try to run this script to see what happens.
| @@ -0,0 +1,160 @@ | |||
| #!/usr/bin/env python | |||
There was a problem hiding this comment.
This code clearly only runs with python2. I think it would be best to specify that, so nobody tries to run it and have it fail.
There was a problem hiding this comment.
Thank you for your review, squilter!
I will fix this code to fit into the dronekit until May 6.
It is great to have a chance like this to contribute to the dronekit!
| # -*- coding: utf-8 -*- | ||
|
|
||
| """ | ||
| © Copyright 2017, Team OpenMakerDrone at Yonsei Univ. |
There was a problem hiding this comment.
This might be a problem with the license and the project rules. Maybe somebody else can weight in.
| set_attitude(pitch_angle = -1, thrust = 0.5, duration = 3) | ||
|
|
||
|
|
||
| print("Setting LAND mode...") |
There was a problem hiding this comment.
Inconsistent use of print "something"and print("something")
… visibility in Python 2
|
@squilter I think it may work with Python 3 now, but I also specified the testing condition I used. |
|
Hello, is there anyone who can give me feedback or can merge this one? |
|
@mrpollo I don't know anything about indoor mode - can you comment on this? @studroid Without trying this my only thought is that it would be good if it came with some docs - like this: http://python.dronekit.io/examples/simple_goto.html The aim is to make it very easy for people to run your example - what are its dependencies? How does it work? What should happen if it is working? What is the special sauce that makes it work (in this case the new mode for AC3.3?). What it can't do that people might expect. That sort of thing. |
|
Thank you for the suggestion, @hamishwillee ! I will try to write the explanation about the code, and if any of you can review my code, it would be a great help when writing the docs, which can lead me to write about specific warning point for users. I'm sure many users are waiting for using dronekit for GUIDED_NOGPS mode. |
|
I am certain that users would like some real examples of GUIDED_NOGPS mode. I'm pretty busy in the next 2 months, but I'll see what I can do to review docs - and that will involve testing this example. |
| """ | ||
| Note that from AC3.3 the message should be re-sent every second (after about 3 seconds | ||
| with no message the velocity will drop back to zero). In AC3.2.1 and earlier the specified | ||
| velocity persists until it is canceled. The code below should work on either version |
There was a problem hiding this comment.
Replace the word "velocity" by "angle" here. When in angle control mode, GUIDED doesn't care about velocity or any information that might come from the gps. The same functions as for ALT_HOLD or STABILIZE are used internally by Ardupilot to control the drone.
| time.sleep(0.2) | ||
|
|
||
|
|
||
| def set_attitude(roll_angle = 0.0, pitch_angle = 0.0, yaw_rate = 0.0, thrust = 0.5, duration = 0): |
There was a problem hiding this comment.
If you don't add a yaw_angle argument here, the drone will always abruptly flip to that yaw angle (being zero) as soon as you call this function.
In my instance of using this code I initialize the yaw_angle argument that I'm passing to this function to the drone's current yaw, so that it just keeps its current yaw.
| # Thrust > 0.5: Ascend | ||
| # Thrust == 0.5: Hold the altitude | ||
| # Thrust < 0.5: Descend | ||
| msg = vehicle.message_factory.set_attitude_target_encode( |
| # Sleep for the fractional part | ||
| time.sleep(modf[0]) | ||
|
|
||
| # Send command to vehicle on 1 Hz cycle |
There was a problem hiding this comment.
Although the timeout for velocity control in GUIDED is 3s, the timeout for angle control in GUIDED and GUIDED_NOGPS is only 1s. Given that, it might be cleaner to increase this rate to, say, 2Hz or so to make sure to never accidentally trigger a timeout even briefly.
This different timeout is also not documented (that I have seen), so it might be worthy to mention it in a comment.
Note also that it will add 1s to the duration passed as an argument, so you might want to take that into account or warn the user that the actual duration will be 1s more than what he gave as an argument.
|
@deb0ch Really good to hear that! :) 👍 |
|
ping... almost 4 months have passed :( |
|
@peterbarker @mrpollo Do you have any comments on this? DK-Python is not currently on my priority list. One thought, the folder and filename are not useful - change_attitude.py |
|
|
|
Thank you for your ping, @amilcarlucas :) It seems I can keep working on this request after next week, so let me know if any modification is required. |
|
Probably |
|
One more month .... |
|
See #712 (comment) . I don't know of the technical merits of the code, but naming it something that means people can identify it easily is a good idea. |
|
@hamishwillee Do you mean that you are waiting for @studroid to integrate the changes for merging this ? |
|
No, I'm not planning on merging it because I don't have time to review it right now. But if I was to put a gating factor, that would be one. @peterbarker Is best person to comment on this. |
|
Thank you for all of your interest on this, and sorry for being late. If any of you can make a change to this request, please make a push or pull request and I will integrate it as soon as possible. Also, It would be great if someone who can merge this gives me feedback, while I know it is a little hard to test because it is a little far from concerns of dronekit, but I'm sure it can help so many dronekit users because there is arising demands for autonomous controlling UAV without GPS :). |
|
Thanks very much for this example. I do have rights to merge, and I'm only slightly afraid to use them. I've pushed up a squashed and mildly patched version of this here: https://github.com/peterbarker/dronekit-python/commits/studroid/guided-nogps Could you have a quick look at that and say whether you're happy for me to squash all of that together and push it into master, please? |
|
Hello, @peterbarker ! Sorry if you are confused because I'm using two different accounts, this and @SJKim0122 . Your modifications are really great, and I made just one comment on the code. Maybe tomorrow would be enough to review them, and some more time needed to write some docs. |
|
On Mon, 4 Dec 2017, studroid wrote:
Your modifications are really great, and I made just one comment on the
code.
Thanks for that. Since I tested it in SITL and It Works For Me, I've
squished everything together and pushed it in.
If there are bugs then PRs can fix that :-)
Also, I think I have to review in more detail about what @deb0ch mentioned.
Yep, better to get this in and have other people get access to it!
Maybe tomorrow would be enough to review them, and some more time needed to
write some docs.
Many thanks for this example. It's something people are very interested
in!
|
|
Just to give some context to my comments, I'm using the set_attitude_target message in a production project. I use it to control my drone's position based on the output of a lidar, and based my code off of this example. So I went through it IRL and all the comments that I made are based on caveats that I encountered, and I have real life testing feedback if you guys need. |
|
Oh, and thanks @peterbarker for merging this, it's giving this example PR some needed movement forward 👍 |
|
On Tue, 5 Dec 2017, Thomas de Beauchêne wrote:
Just to give some context to my comments, I'm using the set_attitude_target
message in a production project. I use it to control my drone's position
based on the output of a lidar, and based my code off of this example.
So I went through it IRL and all the comments that I made are based on
caveats that I encountered, and I have real life testing feedback if you
guys need.
I kind of assumed your comments had already been addressed, sorry!
Looks like I got 2/4 of the issues you raised.
Hopefully @SJKim0122 can test for the issues you raised - preferably by
expanding the script to cross the critical angle, for example.
|
|
Thank you for merging this, @peterbarker , and also thank you again, @deb0ch . :) As @peterbarker mentioned, I think some of @deb0ch 's modifications, such as abrupt yaw flip issue, are remaining to be reviewed. I can modify them, but could you tell me how I can push up the changes If I make them? I don't know how to do on the closed pull request. Maybe just push them to my repository? Also, what do you think of renaming to guided_nogps.py like @hamishwillee mentioned at #712 (comment) By the way, @deb0ch , what kind of project are you working for now? It is just out of curiosity :) |
|
All the changes that you mentioned you can make them in a new PR, since it is the designated way to propose changes to what is already in the codebase (though I'm not related to the DK team, so this is just my humble advice). Our project is about wind turbines inspection 😸 We are making a drone use a lidar to position itself around a blade of a wind turbine (which is stopped during inspection) for helping the pilot not to crash his drone into the turbine and automatically trigger HD photo captures just at the right distance. Originally we were using a Erle Brain but this platform was just too, way too unstable. So unstable that it was impossible to have a secure, reliable flight with this one (without mentioning the literally random system bugs), so we are now switching to a pixhawk + raspi-raspbian combo. I don't know what you're doing or how you could help but any insight is always very welcomed 😺 |
|
On Fri, 8 Dec 2017, Thomas de Beauchêne wrote:
All the changes that you mentioned you can make them in a new PR, since it
is the designated way to propose changes to what is already in the codebase
(though I'm not related to the DK team, so this is just my humble advice).
This is what I was expecting to happen; better to have it in master and
have patches to it than for it to languish outside waiting for more
review.
|
|
It is not taking off everytime shows that Altitude=0.0 and nothing happens in loop please help? |
|
@Arpit355 Are you using SITL or actual Pixhawk-based UAV? I think it would be better to write your request as an issue and mention this pull-request and me, because it's already been merged. :) |
|
@studroid Arpit here I am using arducopter 3.3.0 and in SITL |
|
@Arpit355 i found the same issue in SITL. Did you try on a real drone/plane? what was the result? I am trying to make a line following hexcopter using raspberry and pixhawk. I am able to set GUIDED_NOGPS by messing with mavlink(i am newbie). When i run the example script in SITL, it does arm but doesn't take off. It waits for a few seconds and disarms. I don't understand what it means. I am running on a deadline. Any help would be appreciated. Thanks in advance |
|
I think you have to use V3.4.4 or later Arducopter version to properly use GUIDED_NOGPS mode. Please write an issue using 'issues' tab if you need any further information, so others can find the answers. :) |
|
How to update ArduCopter to version 3.4.4 |
|
@studroid how to update ArduCopter version |
|
@Arpit355 Please never ever just add your requests to closed issues. It is very frustrating for everyone involved. The right thing to do is to ask on the discussion forums. That said, the answer is that this has nothing to do with DK-Python. If you're working on hardware you'll update the hardware using Mission Planner or QGroundControl. If you're working with a simulator you'll update to recent codelines and rebuild the simulator http://ardupilot.org/dev/docs/sitl-simulator-software-in-the-loop.html#sitl-simulator-software-in-the-loop |
Use this example to test GUIDED_NOGPS mode for attitude and heading changes and take-off.