Not many people know but we have an piece of open source software for controlling an Antenna Tracker. It's been built by Tridge (Arduplane lead developer) for use in the outback challenge.
Sadly we have no documentation and, as far as I know, nobody except Tridge has used it. Still given Tridge's track record on building great software I suspect it works well and if it doesn't, I'm sure we can fix it. So to not let this piece of code go to waste, I'd like some help from people who are interested to give it a try and help me figure out how it works.
Here's the little that I know:
- It runs on any of our supported board (APM1, APM2, PX4, Pixhawk, Flymaple and perhaps VRBrain)
- For APM1/APM2 users building the code is as easy as opening our hacked ArduinoIDE and selecting File > SketchBook > Tools > AntennaTracker and then building in the normal way. For PX4/Pixhawk, our autobuilder doesn't automatically build a binary but I can provide one if people are interested.
- It can control a Pan and Tilt gimbal like this or this found on servocity.com.
- It may or may not require a GPS
- It must somehow receive vehicle position updates from the ground station which has the telemetry radio that is connected to the vehicle. Maybe through a USB cable. Tridge probably uses the python ground station, MAVProxy, to passthrough the vehicle position data to the AT but perhaps we can get MichaelO to build out a similar feature in Mission Planner.
- I imagine this antenna tracker could also be used to keep a camera focused on the vehicle which might be good for easing the burden on creating videos of our vehicles.
So if you want to give it a try please do and stick any findings, questions or issues below. Alternatively Issues can go into the issues list.
I'll start sticking things into the wiki as they become clear.
Replies
Greg,
I had a look at the dataflash log you posted a couple of pages back (sorry for taking so long!) and it looks like the pitch servo is hitting it's upper pwm limit (2100). I was wondering if you'd tried reversing the pitch servo by either unchecking the "reverse" checkbox on the MP's extended Tuning page or by setting RC2_REV to +1?
It looks like the tracker thinks it's pointed down at 72deg so if this is accurate then it means it's a control issue and not an attitude estimate problem.
While investigating this I found that we've got a couple of issues with dataflash logging that I'll correct with a new 0.7.6 release. The desired pitch and yaw angles aren't recorded properly.
I believe I am having a parameter issue and cannot get to the bottom of it. I am running arduplane on a computer and sending the data through radio to a Pixhawk that controls my antenna tracker. Immediately after pairing the plane and antenna tracker, the tracker turns to the left about 30 degrees. It stays like this the whole time it tracks the plane. Does anyone have any advice on this or seen this issue before?
IMG_0252.JPG
Do you have wires running closely to your Pixhawk? I'm using external compass and disabled the internal pixhawk compass. The compasses are very sensitive and react to the magnetic field around a wire when a current runs through.
Sounds to me like a compass problem. If you turn the tracker N, S, E, and W does it display the correction in the planner?
To calibrate tracker compass you only power the tracker then connect to MP and run the calibration program.
My first setup I had my Pixhawk too close to my large antenna that had lots of metallic parts. After separating the Pixhawk and the antenna I was able to get a good compass calibration.
.
My tracker is calibrated correctly and points almost exactly where the red line is pointing. The problem comes once I pair with arduplane. It automatically offsets about 45 degrees to the left. I need the tracker to be pointing exactly at the plane. This picture came directly after pairing the two and after the tracker's adjustment. I need the red line (header) to match up with the orange line from the tracker.
IMG_0253.JPG
It looks like YAW_TRIM or incorrect PID settings. AT calculates heading properly (orange line) but tracks with an offset. YAW_TRIM adds an offset to the calculated yaw value, thus orange line will point at the aircraft and red line will show actual "believed to be correct" value, resulting in an offset between these 2 lines. YAW_TRIM is meant for setups with incorrectly mounted antenna (for example an antenna that has a few degerees offset resulting from mounting conditions). YAW_TRIM should generally be 0 for all setups, since it is not meant for compass offset calibration. Bad compass calibration will result in non-constant offsets along rotation range, thus using YAW_TRIM for compensation will only work for certain positions.
If you use position servos your I term may not be sufficient for the servo to reach desired value - there is a IMAX parameter for YAW axis that should be a good starting point. You can adjust PID settings on the fly and observe changes real-time (if your changes are good your tracker will move closer and closer to desired position.
I wanted to edit my comment but 15 minutes passed, so here is the rest of my comment:
-----------------------------
In another words:
AT doesn't operate on raw servo values (in microseconds), it uses abstract values ranging from -9000 to +9000 (It may be half of this range, I don't remember but for the purpose of this explanation it is not relevant). For position servos tracker assumes that +9000 value corresponds to +90 degrees and -9000 corresponds to -90 degrees (again, I didn't verify these values in code but it doesn't matter). Servo values entered in full paramter list (RCx_MIN, RCx_MAX, RCx_TRIM) are used to convert these abstract values to real servo signal at the very end of calculations, long after PIDs. These values correspond to real angles only when tracker base is pointing real north, thus we use PIDs to compensate for errors and offsets. When your tracker base is rotated far from desired value PID needs to come up with rather large values to compensate for that. In general P term is a multiplication of current error (difference between actual angle and desired angle) and P value which means, that the resulting value will never exceed P*error. In your case error is close to 45 degrees, so with low P values it will not produce enough output to reach desired position. I term is used to compensate that (the value is proportional to the time it took to reach the desired value) and if it takes too long, I gets limited by IMAX. Your IMAX is probably around 4000, so I will never be greater than that. If your P value and IMAX are not large enough your sum of Pout+Iout will not be large enought to compensate for error.
This is not a magnetometer issue, since your red line matches actual tracker orientation.
I hope my explanation helps you solve your problem
Hi Kalab,
Yes, I have had that issue before. You can find my posts, photos, and video many pages back but I'll re-post the video here so you don't need to search.
My video of the APM Antenna Tracker uses Jakob Oller's v0.7.2 firmware for Pixhawk. I had replaced my yaw servo with a stronger JR DS8711 digital servo which works much better and doesn't get hot. Although I had an odd yaw offset of 25 degrees, it remained constant and the pitch worked perfectly. Before the second flight, I changed the YAW_TRIM setting from 0 to +25 degrees and the yaw pointed perfectly at the Tarot 650 quad.
APM: Antenna Tracker Test 3 from Gregory Covey on Vimeo.
The YAW_TRIM definitely helps but I can't change the parameter to be above +10. Is there a way to change this in Mission Planner?
I agree with Jakob and Greg (and maybe others) that this is unlikely to be a compass issue because the red line correctly points to where Kalab says the tracker is actually pointing.
So just taking a step back, the issue is either an attitude estimate problem (i.e. compass issue, etc) or a control problem (i.e. PID controller can't get the servo output set correctly to point at the plane). It definitely seems like a control problem.
Any chance you could provide a dataflash log?