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
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.
.
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.
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?
It should be relatively easy to code an auto tune feature. It would of course need more than usual support from MP (setting correct servo type, slip ring or no slip ring, max allowed angles etc). Auto tune feature would take min and max servo values (preferably preset with sliders) and min/max allowed angles together with mechanical limitations (slip ring - unlimited rotation or no slip ring - respect min/max servo values for position servos or min/max angles for CR servos) and set servo reverse and basic pid settings accordingly. It could also perform compass calibration
Yes, use the Full Parameter List in Mission Planner. Ignore the suggested limits.
I made some upgrades to my AT this year which includes the video downlink system. My AT is designed to point an ImmersionRC SpiroNet 5.8GHz antenna to the copter for my 5.8GHz video downlink. The 13dBi gain RHCP patch antenna has a 35 degree vertical and horizontal radiation pattern. If the AT fails to point properly, my ImmersionRC Duo 5800 receiver can automatically switch antennas to a Circular Polarized (RHCP) SpiroNet omni-directional antenna which has about 1 dBic gain. It will be interesting to see this summer how the AT performs using my APM copters and planes, which also have the Circular Polarized (RHCP) SpiroNet omni-directional antennas.
For the telemetry links, the AT uses an RDF900 to talk to my Tarot copters, Skywalker plane, and FireFLY6 VTOL. For the GCS link, the AT uses a 433MHz telemetry set so it doesn't jam the 900MHz telemetry. This has been working very well with Mission Planner v1.3.34.
I recently changed both the position and antennas of my RDF900 unit on the AT because it was interfering with the Pixhawk control of the servos. At first, I thought it was because I was using the Pixhawk to power the RDF900 unit but even after changing it to a 5v BEC the problem persisted. If I placed my hands over the antennas, the problem was gone. My power level is set to 25 (not 20 or 30max) so I may reduce this to 22, if needed. The new position of my RDF900 greatly reduces the radiation interference to the servos. Also, changing from the smaller antennas to the longer antennas reduced the interference even more.
Looking good. While doing testing for the 0.7.5 release I also noticed putting the [3DR] radio close to the servos caused them to act up.
-
33
-
34
-
35
-
36
-
37
of 104 Next