Servers by jDrones

Tracker-1.1 Officially Released

Tracker 1.1 should work with all the supported boards that work for the other vehicles. In general we leave it up to the users to decide which board is best for them but in any case, if cost is an issue, some of the options are at least as inexpensive as the old APM2.x boards were.

Hi Guys, I’m wondering if there is a bug with servo limits. My tracker is 360 but only seems to work 180.
When it reaches a servo limit, it doesn’t reverse. It only reverses and starts tracking again when the target is 180 behind the antenna.
It’s pretty much what this post describes as bug #2:

https://diydrones.com/xn/detail/705844:Comment:2251277

Am I missing a setting somewhere?

a log would help us diagnose,

so the tracker reaches its limit, you would expect it to go the ‘long way round’ to its other limit to continue tracking from the other limit. Instead it waits until the target can be reached ‘the short way’

Hi Peter, Thank you for responding. Your description is accurate.
Here is a link to the log file. This is running the tracker with arduplane sitl loitering around the tracker at 500m radius.

https://tmpfiles.org/download/23975/00000144.BIN.zip (2hours retention)
or here
https://valtn.me/tmp-files/dl/80294e3db146f6f644158667114ad422/00000144.BIN.zip (3days retention)
Let me know what you think!

not had a chance to look at the log but this is the bit of the code to check over


I will see if I can reproduce on my tracker and then we can do a patch.

Thanks Peter. I will try to make sense of those variables to understand the “outside tracker range” conditions.

the code looks abit of a mess, but I have had a look at your logs, can you try setting the yaw range to less than 360, like 355 deg.

Would be nice to support greater than 360 deg so you get abit of overlap, will only work with position servos, we have no idea where the base is in relation to the tracker for continuous rotation.

Thank you so much that seems to work! I spent quite a bit of time on this today but couldn’t figure it out. I got my hands dirty and learnt how to print variable values and rebuild a firmware!

1 Like

great your getting in to the code, it can be quite intimidating but it is not as complicated as it looks. I have done a bit of a tidy up of the code in that area of tracker prior to having a proper look for the potential bug. Would be great if you could test it and see if I have broken anything by mistake, in particular the pitch limits.

The PR is here, and I had built a cubeblack firmaware here. Note that this is built on master so there may also be some other changes from the stable release.

I will definitely take look at your new code this week or over the weekend. Tonight I went to test the tracker with a real plane: It worked really good! the crowd was impressed (i couldn’t really see it for myself since I was wearing goggles). It lost track once or twice, but recovered after a minute or so.
I will review the logs tomorrow to see if I can improve the pids.
If you don’t mind me asking, what did you see in the logs that pointed out that 360deg of yaw movement might be the problem? In your opinion, what are the important metrics to review in the logs of the antenna tracker?
Best Regards,

Hi Peter,
So I tried your firmware today, but I am seeing an issue with pitch. It only aims straight up 90 degrees. In servo testing mode it moves fine. The compass device ids got moved around in this version of the firmware, so I reset all params and configured everything from scratch, and did a compass calibration dance with the tripod.

I also did additional testing on v1.1.0. I found that the tracker doesn’t “go the long way around” when it reaches yaw limit and when the tracker pitch is a bit higher than 17 degrees. RTL with 200m radius and 65m altitudes is fine, but at the same radius and 70m altitude the tracker starts the “reverse” 360 move and aborts it rapidly. Same behavior at double the radius and altitude. I seem to be able to reproduce this consistently.

I should note than on my antenna tracker, I have the Here GPS moving with Yaw, but not with pitch (my original thought was to keep the GPS puck upright for better reception), so I am disabling compass #1

Thanks for testing!, sounds like I have also made a error with my new pitch limits.

defiantly sounds like there is something funny going on with the conversion to between body and earth frames possibly reducing the yaw range further would improve this. But if the code was working correctly it should cope, so I think there is defiantly a bug.

Yeah that should be fine, it will report a bad ekf fairly quick if it was including compass 1 in the calcs.

I think I may have figured it out. I now have my tracker “reversing” properly when it reaches yaw limits at any pitch.

TBH, I don’t fully understand the BF and EF concepts, but adding this condition seems to do the trick for me:
In addition to

(yaw_angle_error_lower < ef_yaw_limit_lower) && (yaw_angle_error_upper > ef_yaw_limit_upper)

I think we need:

(yaw_angle_error_lower > ef_yaw_limit_lower) && (yaw_angle_error_upper < ef_yaw_limit_upper)

Which I refactored like this to make lines shorter:

git diff AntennaTracker/control_auto.cpp
diff --git a/AntennaTracker/control_auto.cpp b/AntennaTracker/control_auto.cpp
index b6aac57159..61d65938a9 100644
--- a/AntennaTracker/control_auto.cpp
+++ b/AntennaTracker/control_auto.cpp
@@ -114,18 +114,22 @@ bool Tracker::get_ef_yaw_direction()
         yaw_angle_error_lower = ef_yaw_angle_error;
     }

+    float lower_yaw_diff = ef_yaw_limit_lower - yaw_angle_error_lower;
+    float upper_yaw_diff = yaw_angle_error_upper - ef_yaw_limit_upper;
+
     // checks that the vehicle is outside the tracker's range
-    if ((yaw_angle_error_lower < ef_yaw_limit_lower) && (yaw_angle_error_upper > ef_yaw_limit_upper)) {
+    if (((lower_yaw_diff > 0) && (upper_yaw_diff > 0)) || ((lower_yaw_diff < 0) && (upper_yaw_diff < 0))) {
         // if the tracker is trying to move clockwise to reach the vehicle,
         // but the tracker could get closer to the vehicle by moving counter-clockwise then set direction_reversed to true
-        if (ef_yaw_angle_error>0 && ((ef_yaw_limit_lower - yaw_angle_error_lower) < (yaw_angle_error_upper - ef_yaw_limit_upper))) {
+        if (ef_yaw_angle_error>0 && (lower_yaw_diff - upper_yaw_diff < 0)) {
             return true;
         }
         // if the tracker is trying to move counter-clockwise to reach the vehicle,
         // but the tracker could get closer to the vehicle by moving then set direction_reversed to true
-        if (ef_yaw_angle_error<0 && ((ef_yaw_limit_lower - yaw_angle_error_lower) > (yaw_angle_error_upper - ef_yaw_limit_upper))) {
+        if (ef_yaw_angle_error<0 && (lower_yaw_diff - upper_yaw_diff > 0 )) {
             return true;
         }
+        //return true;
     }

     // if we get this far we can use the regular, shortest path to the target
1 Like

I’ve tested this fairly extensively with SITL and with a real plane for 2 hours. My tracker works really good now!
I made a PR here: https://github.com/ArduPilot/ardupilot/pull/12068

Hi guys - I’m running the new firmware but the compass calibration doesn’t seem to function at all? The ‘enable compasses’ checkbox doesn’t activate when clicked (although compasses are enabled in params) and hitting ‘start’ for the onboard mag calibration doesn’t seem to do anything. Anyone else having this issue?

Hi Adam,
I recently spent quite some time trying to setup tracker 1.1.0 running on a Pixhawk v1 with a PT785-S tracker frame. I have yet to get it working properly, and mag cal is one of the issues I had.

I found that none of the initial setup routines would run for me, the accelerometer and magnetometer calibrations would simply fail to start. After much messing about, I flashed the current stable Plane build and ran all of the calibrations from there. I then save the parameter file, re-flashed Tracker and manually edited all of the magnetometer and accelerometer parameters to match the ones obtained with plane.

This gave me a close-enough calibration to be usable. The strange thing is that after I had done this, the magnetometer calibration now works in Tracker :thinking: I don’t know enough about how this all works at a low level but it’s possible that if you throw some dummy values in for the mag it might fix whatever is stopping the calibration routine from running.

I’ll be curious to see if anyone else has had these issues. At this stage the software part of my tracker seems to be working - I have the SITL connected with the tracker and can see both on Mission planner. The tracker has an orange line that tracks the simulated plane, but the physical tracker constantly oscillates in both pan and tilt and is even exceeding the limits I have imposed in the extended parameters section to set the range of travel. I’ve currently run out of time to play more with it but the whole operation currently seems a bit wacky.

Hi Phillip - I’m using a pixracer and the PT785-S. I was just thinking about how I could calibrate in another firmware then import back, so your suggestion is timely :smile:

I’ll give that a try and report back. Hopefully the devs can find a minute to take a look at the compass calibration.

@pmoss @Adam_Kelly You have to be disarmed to run a calibration. Tracker auto arms so you will have to dissarm via your ground control software and/or switch to stop mode.

1 Like

Hi Peter - I had tried not arming and/or disarming with the safety switch but that didn’t seem to help. Your suggestion made me give it another try though, and I discovered you have to hit ‘start’ on the compass calibration when you are not connected to the antenna tracker at all. I’m using the ESP8266 wifi module to connect to MP from the pixracer, unsure if that’s what was giving me the grief. Either way, by hitting start with the tracker disconnected, the connection happens and the calibration starts. At last!
The issue remains that I cannot check the ‘enable compasses’ box - but the compasses are definitely enabled in the params list so not sure that’s a huge problem.

This is not arming/disarming that is just the saftey state. You will have to manually disarm via the GCS.

Servers by jDrones