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
MRC = multi-rotor craft?
The way it works is it maintains an estimate of where the vehicle is using it's location, heading and groundspeed (reported by the vehicle on the telemetry link). Those updates probably arrive at 1hz ~ 5hz so between those updates it just projects forward where it thinks the vehicle is based on the last update.
I suspect there's a sudden jump in the vehicle's estimated position when an actual update arrives. When the vehicle is far out, that jump doesn't affect the tracker's desired pitch and yaw angles much but when the vehicle is close the angular change could be very large.
Another likely problem is the lat, lon positions are reported as 4bytes floats instead of 4byte integers which reduces their accuracy to about 1m. If we used integers it would be 1cm (normally you'd think floats are more accurate but not in this case). This could also lead to very rough estimates of the vehicle's position and thus target angles.
The controllers in the tracker are pretty simple and could certainly be improved in many ways including fixing the issues above and adding extra filters to keep it all smooth.
Ok, thanks Randy and Ted. I suspect that your assessments are right on target. Yes, MRC is Multi-Rotor Copter (or Craft). I can try a test sometime and hopefully get a video where I fly the MRC closer and then much farther away to observe the AT behavior. I am also toying with the idea of buying a FireFly6 VTOL which would behave like both an MRC or plane, but, I have not found anyone that has purchased one yet on either RCG or DIY Drones.
I have similar observations. In my case the pitch axis was way off with short distances. It is caused by big baro differences, especially at low altitudes - I noticed 15 meters difference in altitude reported by BARO with no more than 50 meters of distance between tracker and "MRC". I solved this by simply using GPS altitude instead of BARO altitude and it works fine.
You also need to keep in mind that your tracker uses it's own GPS and it doesn't do all the fancy filtering that ArduCopter does - what it means, is that it relys on raw GPS data which is jumpy and ugly. If you consider GPS accuracy of 5-10 meters on the tracker side, 3-5 meters on Copter side and short distance between them it may result in an extreme situation where tracker "thinks" it is on the other side of MRC and points wrong way. I solved it by assuming, that my tracker is not moving (or moving slowly) - I simply avarage GPS readings (I use 95% of previous location and 5% of the most recent location) so when a big jump occurs it only affects the position by 5% of it's magnitude. But again, it is based on assumption, that I place my tracker on the ground, apply power and don't move it during flight (I can move it a few meters back and forth but it generally shouldn't be mounted on a vehicle with this kind of GPS averaging).
Seems to make sense, the closer your vehicle is to the tracker, the higher the gains would have to be on the tracker to keep up. A 10 yard motion close in is a much higher angular motion than 10 yards out. Increasing the gains can then add instabilities to the loop performance of the tracker.
For far out (i.e. slow changes to the AT), I would not expect to see much difference in AT performance for a real vehicle versus a simulated one.
Of course, that remains to be seen :)
Has anyone the tracker working with version 0.71?
I have a lot of problems getting it to work. 0.5 was working fine and since only the continouus mode was added I updated to 0.71. Is there a way to get back to 0.5?
I tried 0.71 with a Navio and with an APM2.5.
Pitch is not following the vehicle, but is reacting if I tilt the tracker mount, keeping the antenna level all the time.
Yaw is working most of the time. Changing from servo test mode back to any other mode does nothing. Only power cycling gets the tracker working again. The tracker sometimes (this happens with powering up or after I played around with the various modes and settings) also does not track in the vehicles direction, but at a random offset (sometimes 90° or more). I first thought this only happens with CR servo mode, but it also happens with on/off mode.
Again, only power cycling helps.
I am using an APM2.5 right now.
I currently have three vehicles (Plane/Pixhawk, Copter/APM2.5, Rover/Navio) and the tracker sometimes does not recognize the vehicle, although the 3drradios are connected and exchanging data. With 0.5 I had established a way of getting everything to work. First connect power to the vehicle, wait for a GPS fix, then switch on the tracker.
With 0.71 this does not work, because the tracker would not recognize the vehicle. Switching on the tracker first, vehicle second works, but the time it takes to get a GPS position from the vehicle, is really hard for the servos, because the tracker turns and turns.
I really would like to go back to 0.5, if anyone has the hex file please send it to me.
There were a lot of changes between 0.5 and 0.7.1 other than CR servo mode and it is hard to tell where is the problem. In my opinion though the problem is somewhat related to your problems with 0.5 version - it should work without your "special way of getting it to work". Currently I have a custom firmware in my tracker based on 0.7.1 (I accidentally deleted the code when I deleted the repository and I have to rewrite it from memory - I fogot to backup my branch, I only backed-up main tree....) and it works perfectly (I changed from baro-based pitch to gps based pitch plus added extensive GPS averaging on the tracker side). I think you can revert to 0.5 via Mission Planner. If not, I can compile 0.5 for you.
I suspended my work on tracker firmware for the time being but I will get back to it as soon as I finish my other projects. For now my tracker works as expected (I still have some problems mentioned in my previous posts but I have working workarounds). I simply just take my tracker out of the car, place it anywhere I want and power it on - as soon as my datalink gets a valid connection it is tracking with unnoticeable error (it is difficult to tell if there is any error at all). It doesn't matter if I power-on the tracker first, it even works if I turn it on mid-flight (happened a few times when my tracker battery died during flight).
@Jakub: could you provide your code (zipped sources) if you have it already restored?
At last I got items from Servocity so I'm going to build my own AT with APM 1.4 controlled.
Hope I will get it to work somehow ;-)
I replied to your PM messages about the code.
I have a significant problem which stops me from going further with the AntennaTracker - all the changes from .pde to .cpp files made it almost impossible to compile for a non-guru user.. I tried Arduino, Eclipse, make... I am obviously doing something wrong and the manuals on ardupilot.com are clearly outdated. There will be no updates until I solve this problem.
I was able to compile it in linux using make, what errors are you getting? If it is complaining about missing libraries, be sure to run make clean first.
I finally decided to make a fresh install of Ubuntu on my PC and it works like a charm. I used a tutorial for linux and make + I adopted eclipse tutorial to make it work under linux. It still doesn't work with my windows machine though. Anyway, I was able to modify all the code I had at the time of 0.7.1 release and it works fine. Now I need to split it into several branches and create pull requests for each of them (just as Randy suggested in my previous pull request: https://github.com/diydrones/ardupilot/pull/2350 )
I can compile for apm1, apm2, px4 and pixhawk so if anybody needs a special firmware or some modifications it shouldn't be a problem to provide a custom .hex file.
-
74
-
75
-
76
-
77
-
78
of 113 Next