-
Notifications
You must be signed in to change notification settings - Fork 17k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Antenna tracker: mend most things #10452
Conversation
@@ -278,6 +290,11 @@ class Tracker : public AP_HAL::HAL::Callbacks { | |||
void tracking_manual_control(const mavlink_manual_control_t &msg); | |||
void update_armed_disarmed(); | |||
|
|||
// Mission library | |||
AP_Mission mission{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need the mission object for anything? we don't support missions.. is it required in order to hold the home position?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its just so we can use the GCS mission messages, the mavlink gcs common returns errors to mission planner when it tries to read way point zero on arming. The fix is to construct the mission library so its not nulptr, the other way to fix is add custom mavlink messages for all the mission messages that know not to look for the mission library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worthwhile to change AP_Mission to check for nullptr callbacks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, sounded like such a good idea that I went ahead and did it. See #10542
Using that, you probably don't need to create a mission instance. if you did, you could just pass it nullptr functions instead of these empty ones.
@IamPete1, this looks really good, thanks for taking this on. Just a couple of cosmetic things and then I'll pull it in. |
Commit messages need fixing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two commits need to be folded together.
4d0bedd
to
324c13b
Compare
On Fri, 8 Feb 2019, Peter Hall wrote:
I can put the if statements the other way round, the key thing is not to overwrite the current location when calling the ahrs get position
Yep!
|
This now also fixes the communications lock out issue, dare i say, maybe we could do a release, I think it would get lots more use with all the new boards supported |
Really looking forward to a new release, when possible! I remember trying and failing to get the 1.0.0 firmware running on anything but a Pixhawk 1 (a PX4-v2.4.8 clone), so supporting more modern hardware (e.g. cheaper boards, better compasses) would be a boon. It was difficult to get an accurate heading in some situations. Now I just need to figure how to tune the PIDs better. At the very least, having someone take a look at the firmware to fix current bugs is great. |
@Evan1010 Should be a new beta an a week or two. To help with PID tuning this included gcs_pid mask param that sends back the values to the gcs. If your keen to get started i can build you a firmware. |
let's get this passing CI and re-evaluate for merging! |
please rebase this, it's failing on the AP_Logger compile failure thing that snuck in briefly. The particular commit you're basing this on is broken. current master is better |
05331e4
to
14587ec
Compare
@magicrub re-based and fixed that if, hopefully should pass checks now. Thanks for taking the time to have a look at this. |
action from the dev call is for @peterbarker to have another look now that it's been rebased. The rebase has sadly been broken again so perhaps @IamPete1 could rebase again.. or maybe Peter can just ignore that rebase issue as part of his review |
14587ec
to
8a34924
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see 1.5 changes needed. The params are still being corrupted and @peterbarker noted something about the pitch2srv angles
8a34924
to
51701cb
Compare
Things aren't factored quite right in the commits here. I've pulled out the compass functions here: #10653 |
8bb56df
to
f136237
Compare
@peterbarker once #10664 has gone in this is all i have left in this PR. |
I think this just needs a merge now, nothing controversial left |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be two commits.
Which mission commands currently fail without the instantiation of the mission object?
@peterbarker Mission planner (possibly also otters) attempts to read waypoint zero on arming resulting in a error. I thought it was easier to construct the mission library than to add a special case to catch that request. |
f98b0ba
to
21276ee
Compare
On Sun, 10 Mar 2019, Peter Hall wrote:
@peterbarker Mission planner (possibly also otters) attempts to read waypoint zero on arming resulting in a error. I thought it was easier to construct
the mission library than to add a special case to catch that request.
We can vastly improve home-storage by using the library, so I'm not
complaining.
But MP asking for waypoint-0 for home is weird. I wonder if that's an
AntennaTracker-special thing, and whether the recent home improvements may
have removed the requirement for it.
|
@peterbarker the issue is still there on master, I think mission planner does it for all vehicles |
Merged, thanks! |
This fixes a few of the things broken with tracker. However still some issues with the pass through telemetry. I have been connecting directly to tracker with USB. When connected to copter it will only get its location back and a few messages, however with plane it seems to get back all the information it should. When connected to plane or copter there is no GCS control of either tracker or the remote vehicle. My theory is that no messages are getting to tracker or passed on, therefore only getting back what information is streamed by default? Before any connection is made to the remote vehicle tracker behaves as it should can change modes and parameters. Would be great full for some advise on the this pass through issue.
Anyway fixed in this PR are: