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
Hi,
GPS altitude branch doesn't work (yet), I had it done but I lost my code and it worked fine. In this branch I tried to recreate it from memory and I can't remember if I finished it or not. The main advantage of this approach is when your tracker is stationary - it then averages the gps data to get proper altitude and position. It worked perfectly for me as opposed to baro, since at short distances barometric pressure changes close to ground are significant (termic, wind rotors between buildings etc). Moreover, tracker by default zeros the difference between its own baro and target baro during first connect, so if you power on your tracker when vehicle is in the air the pitch will be off (it assumes that it is at the same altitude as the target during initial connection). This problem is not visible with GPS approach. I will finish it someday but for now the weather outside is not encouraging.
As for pitch limits - my previous tracker (I don't have it anymore, I had to disassemble it because it was made of an old camera gimbal) had slip rings on both pitch and yaw and thus my antenna could rotate in pitch without any mechanical limitations (the frame was big enough for the antenna to pass through). In my current tracker I have position servos for pitch and CR servos for yaw (with slip ring on yaw). Your concerns though are only valid when your tracker flips/trips (due to wind for example). In normal operating conditions (tracker more or less level in relation to ground) software limits will not allow it to crash into your frame. I am planning on implementing hardware limit switches to prevent that (on my long todo list).
I am also planning to extend the meaning of "servo_type" parameter - for example:
0 - 2 position servos
1 - one position, one CR
2 - one CR, one position
3 - both CR
4 - both on-off (I doubt anyone uses that, it may only work with very slow DC geared drive that doesn't have proportional control)
The reason for using one parameter instead of 2 is that I am not that comfortable with adding new parameters - I had issues with that before (mostly due to lack of experience in that area)
Hi Jakub,
I have replaced my Pixhawk on the working AT with an Arduflyer 2.5.2 controller with a built-in compass. It seems to work fine but I have not tested it outdoors yet due to the cold windy conditions. I would prefer to use your latest firmware but have lost the link. Can you post your firmware or link again please?
I hope that your schedule becomes less busy so you can spend more time playing this holiday season. :)
Serial3 in the Full Parameter list was for the GPS so when I tried changing those settings I lost my GPS and still had no telemetry. I had the other Serial port settings to the proper telemetry baudrate and Mavlink protocol but it didn't help. Maybe Mission Planner has changed the serial port numbers around for the Pixhawk.
This is how the serial ports show up in Mission Planner. Serial3 is now for the GPS so it no longer matches the Wiki instructions for APM, only Pixhawk. However, I did change Serial3 from 38 to 57 and the protocol from 5 to 1. I lost my GPS comms and did not gain telemetry.
Hi,
sorry for late reply. I can see you found what you needed :) As others mentioned - use solder jumpers to switch over to UART2. I didn't have time to familiarize myself with latest changes in APM code (APM hardware seems to have been dropped in favor of Pixhawk) and I am running out of APMs so I will most likely build new tracker using Pixhawk. My previous tracker has been disassembled (the frame I used was a refurbished copter gimbal) and I have a simple frame with stepper motor in YAW axis to see if stepper motors are any good for tracking
I found Jakub's v072 firmware for APM and loaded it up without issue. I re-calibrated the on-board compass with the AHRS_ORIENTATION parameter set to Pitch90 and it seems to work well on my initial testing indoors with my hexacopter in another room. I miss having my telemetry channel when the USB is connected like on my Pixhawk version. Perhaps I can make use of the third serial port on the Arduflyer v2.5.2 board.
JakubAntennaTracker0.7.2APM2.hex
Hi Greg,
I have a Raspberry Pi connected to my HKPilot 2.5.2 via USB. I soldered extra pins to the HKPilot to use UART2 with the 3dr radio, but I think there is a way to assign the telemetry port to UART2 with a solder pad
Hi Sebastian,
Thanks for the memory jog. It has been a while since I used a 2.5.2 board instead of a Pixhawk but I found the information here in the APM Wiki. I have to change the default jumpers from UART0 to UART2.
I tried using the Wiki example for trace cuts and solder jumpers on my APM v2.5.2 board but was not successful in getting a telemetry connection using UART2. I checked the jumpers with a multimeter so I am not sure why this failed.
For now, I will leave it in the original v2.5.2 configuration since it works when not connecting to the USB port.
-
42
-
43
-
44
-
45
-
46
of 113 Next