Add an Automatic Antenna Tracker (AAT) backpack

[CapnBry]

Adds a new type of VRX backpack to be used for Automatic Antenna Tracking with two types of input (via compile)

• Backpack wireless (ELRS ESP-NOW) using ExpressLRS 3.4's backpack telemetry mirror
• EdgeTX telemetry mirror over UART

Hardware

• One ESP8266 of any kind, such as a Wemos D1 Mini, or an ExpressLRS RX (the RF chip is not used, only the ESP)
• Two Servo Outputs (one is optional). Requires at least one servo output be connected to control Azimuth tracking, or two for both Elevation and Azimuth tracking. A standard ExpressLRS 4 pin (GND, VCC, TX, RX) receiver can be used, but it is much easier to use a 5ch PWM RX which has the two servo outputs
• OLED Display (optional) SSD1306 I2C OLED. Displays GPS information until home established, then displays Elevation / Azimuth / Servo Position as well as the expected GPS update rate
• Button (optional) Press once to reboot to wifi, press again to reboot to normal mode. Gotta do something different with this eventually.

The software currently expects that the azimuth servo be a 180 degree servo and the output must be geared at least 2:1 so the range of motion of the device can reach all 360 degrees without jamming up the servo. I used the Sentinel AAT Lite 3D prints which have a nice geared setup for the Azimuth servo. I have reserved config space in case we want to add a 180 degree azimuth + flip algorithm for direct servo driving.

GPIO	ESP PWM RX output	Function
0	1	Button (press to reboot to wifi / normal), other side of button to GND
1	2	OLED SCL / DEBUG TX
3	3	OLED SDA / CRSF TelemMirror Input
9	4	Azimuth Servo PWM output
10	5	Elevation Servo PWM output
16	-	LED (inverted polarity)
A0	VBAT	Analog VBat input (external resistor divider)

Software

ExpressLRS has a low update rate for telemetry so in Standard telemetry mode there is about a 5-6s update interval. The user can select a higher TLM ratio to increate the GPS update rate, but that generally isn't needed at long range due to the low angular velocity required to keep the antenna pointed correctly at long range. I've also implemented an azimuth projection algorithm AI (😉) that maintains a constant angular velocity for one expected GPS update interval to keep tracking between updates.

Home position is captured when the GPS satellite count reaches at least 5 satellites and the AAT azimuth should point directly North when the servo is centered.

I've added a CRSF-parsing Module base class as well for who knows what shenanigans.

Configuration

I updated devWIFI a bit to bring it more in line with how mainline loads the config. Instead of generating a string it now uses a JsonDocument and other things (like AAT) can add their config to it as well.

• satelliteHomeMin = 5;
• servoMode = 0; // 2:1 or Clip180, FUTURE: Flip180
• project = 0xff; // FUTURE projection mode
• centerDir = 0; // which direction does the servo center point
• servoSmooth = 5;
• servoLowAzim = 500;
• servoHighAzim = 2500;
• servoLowElev = 1000;
• servoHighElev = 2000;
• VBatScale = 410; // same used in PWMP5/6, or 292/-2 for RM
• VBatOffset = 12;

Testing

Added python/utils/gpscsv_to_crsf.py script. This takes an GPS log CSV (exported from blackbox log using blackbox_tools) as input and plays back the GPS position updates in real time at the specified interval. Updates between the specified interval are dropped.

# Export the blackbox log to CSV using blackbox_tools (0.4.4 used)
blackbox_decode.exe "D:\LOGS\LOG00015.TXT"
# generates "D:\LOGS\LOG00015.01.gps.csv" among other files

# Send to VRX backpack directly using the UART (requires DEBUG_LOG enabled on VRX backpack for pins to be hot), 5s interval between GPS updates
python .\python\utils\gpscsv_to_crsf.py -P COM38 "D:\LOGS\LOG00015.01.gps.csv" 

# or with a 3s interval with 2s of random jitter added (3-5s interval)
python .\python\utils\gpscsv_to_crsf.py -P COM38 -I 5.0 -J 2.0 "D:\LOGS\LOG00015.01.gps.csv" 

# Send to a TX backpack for sending over wireless (MSP wrapped CRSF telemetry)
python .\python\utils\gpscsv_to_crsf.py -P COM38 -m "D:\LOGS\LOG00015.01.gps.csv" 

[CapnBry]

Anyone know why I am getting that github build error? Seems like it is trying to build with a closing bracket on the target name:
UnknownEnvNamesError: Unknown environment names 'AAT_ESP_Backpack_via_UART]'

When I run the prebuild script on my windows PC + bash I get it without it

targets=["AAT_ESP_Backpack_via_UART","DEBUG_ESP_RX_Backpack_via_UART","DEBUG_TX_Backpack_via_UART",\
"DEBUG_ESP32_TX_Backpack_via_UART","Fusion_Builtin_Backpack_via_UART",\
"HDZero_RX51_ESP_RX_Backpack_via_UART","HDZero_RX51_ESP01F_Backpack_via_UART",\
"HDZero_RX51_HappyModel_EP82_VRX_Backpack_via_UART","HDZero_RX51_ESP32_Backpack_via_UART",\
"HDZero_Goggle_ESP32_Backpack_via_UART","Orqa_ESP_RX_Backpack_via_UART",\
"Orqa_ESP01F_Backpack_via_UART","Orqa_HappyModel_EP82_VRX_Backpack_via_UART",\
"Rapidfire_ESP_RX_Backpack_via_UART","Rapidfire_ESP01F_Backpack_via_UART",\
"Rapidfire_HappyModel_EP82_VRX_Backpack_via_UART","Rapidfire_ESP12F_Backpack_via_UART",\
"RX5808_ESP_RX_Backpack_via_UART","RX5808_ESP01F_Backpack_via_UART",\
"RX5808_HappyModel_EP82_VRX_Backpack_via_UART","RX5808_ESP12F_Backpack_via_UART",\
"RX5808_Diversity_ESP01F_Backpack_via_UART","Skyzone_SteadyView_ESP_RX_Backpack_via_UART",\
"Skyzone_SteadyView_ESP01F_Backpack_via_UART","Skyzone_SteadyView_HappyModel_EP82_VRX_Backpack_via_UART",\
"Skyzone_Onboard_ESP32_Backpack_via_UART","ESP_TX_Backpack_via_UART","STM_TX_Backpack_via_UART"]

[froqstar]

Wouldn't it be more elegant from a technical perspective if, instead of receiving telemetry on the handset module and then forwarding it via the (hopefully present) backpack via ESPNow, to put a second RX in the tracker which just listens for ExpressLRS GPS telemetry over the air?
Then this RX could also have a directional antenna which is tracking the aircraft together with the VRX antenna, resulting in possibly better telemetry reception at long range than via the handset.

[CapnBry]

Wouldn't it be more elegant from a technical perspective if, instead of receiving telemetry on the handset module and then forwarding it via the (hopefully present) backpack via ESPNow, to put a second RX in the tracker which just listens for ExpressLRS GPS telemetry over the air?

Sure, you could. You could also transmit it directly from the TX module over bluetooth, or read it from the video stream, or have a secondary connection or MAVLINK it 😀

Years ago now (wow ELRS is old) I looked at doing what I called a "completely passive receiver" option, that allowed an RX to listen to both sides of the conversation and dump all the packets. The small issue there is that telemetry doesn't come all at once, it comes in bits and is reassembled by the receiving side, passively requesting retransmits by not acking the fragment. This would mean I'd have to really put a lot of specialized code into the telemetry receiver code to be able to just give up on the whole item if it missed a packet or if it misses multiple it could start combining packets without knowing. That and then adding extra code for the tracking and inspecting the internals of the telemetry packet... all that is just too much to build into the core product when the core product is really is not a clean design to begin with.

The bigger reason for this is because not everything has an ExpressLRS RX in it, but some things do have ESP in them. Those things, like the Sentinel AAT, support this wireless protocol so they get their data that way. Making our own AAT was just a fun hour hack to get it working and has no impact on the performance or safety concerns of the ELRS core. It takes a feature we support, adds a super cheap way for anyone to use it, and doesn't create any risk to the core or create a whole new project to do so.

So why wasn't it done another way? Because there are a lot of ways it could be done, and this felt like the lowest risk and had zero technical hurdles to overcome. (And also doesn't have the logical followup request of 'if the AAT is receiving the telemetry, can you make it send the channels data too, wirelessly from the handset?', which is possible yes but I don't want to work on that)

[froqstar]

Thanks for the detailed explanation, which makes sense to me. I didn't think about packet loss/resending at all.

[CapnBry]

Oh my glob I am the happiest person alive I managed to commit code that github can build. Let's drink!

[pkendall64]

Rather that jamming the AAT code in with the VRx backpack do you think it would be better to have another backpack type like the timer PR #114 is doing?
Or am I just something important here?

[CapnBry]

Rather that jamming the AAT code in with the VRx backpack do you think it would be better to have another backpack type like the timer PR #114 is doing? Or am I just something important here?

😂 I think it is obvious: because the current source code currently only has two types of backpack: TX and VRX. Which one is this? It receives so it is a VRX type.

I can update it to move the config and to its own new internal "type" thing if you'd prefer. I'd still use the html/js though because copy-pasting the existing stuff then modifying it doesn't seem like a very smart way to go for maintainability. That's really the only difference right? It just seemed to me the smartest way to go was to extend the config rather than have multiple copies of the same thing (config / webui) that now all need to be maintained separately when the "base" they were copy-pasted from change.

[pkendall64]

Rather that jamming the AAT code in with the VRx backpack do you think it would be better to have another backpack type like the timer PR #114 is doing? Or am I just something important here?

😂 I think it is obvious: because the current source code currently only has two types of backpack: TX and VRX. Which one is this? It receives so it is a VRX type.

I can update it to move the config and to its own new internal "type" thing if you'd prefer. I'd still use the html/js though because copy-pasting the existing stuff then modifying it doesn't seem like a very smart way to go for maintainability. That's really the only difference right? It just seemed to me the smartest way to go was to extend the config rather than have multiple copies of the same thing (config / webui) that now all need to be maintained separately when the "base" they were copy-pasted from change.

I can see this, and I can see that we may even add more functionality to the VRx backpack which would make the V part even less relevant!

[anti-vaxxer]

I'm pleased to see you develop this, thanks CapnBry.

I want to make a tracker with a continuous rotation servo and slip ring, to eliminate the brief signal loss when the tracker reaches it's limit and has to quickly turn around.

I also want to have a GNSS module and magnetometer so the tracker can be moved and pointed in any direction, which also makes it possible to use it on a moving car etc..

what do you think about these features?

[CapnBry]

Not as part of this PR but extending the functionality down the line is an option. What you're asking for requires quite a lot of new things to be added:

• Magnetometer support
• Continuous rotation mode
• GPS support in NMEA, UBLOX, various baud rates, etc. It is easy to support just one specific GPS but there are a ton of variations out there so it would need a whole giant unit just to be compatible with an acceptable amount of hardware

I don't want to discuss any of that in this PR, or anywhere else really at this time as there are more useful things to work on.

[YI-BOYANG]

I love this PR.

[Lance0724]

I love this PR.
When will it be released? and provide a wiki about user guide.
Do I need to update the TX backpack to use this PR?

[CapnBry]

Do I need to update the TX backpack to use this PR?

You need at least the version that supports sending telemetry from the backpack, which I believe is ExpressLRS 3.4.x but I am pretty sure any Backpack firmware from the past year or so will work. I did not make any updates to the TX Backpack.

[sarahdaviscc]

Is the RX backpack capable of outputting CRSF packets?

If so I can use the backpack system to supply CRSF telemetry to a Mini Crossbow AAT system which would make life a million times easier for users of this system.

[pranas]

One ESP8266 of any kind, such as a Wemos D1 Mini, or an ExpressLRS RX (the RF chip is not used, only the ESP)

Would it be possible to use the RF chip of ELRS RX to receive telemetry for this? It would be great for the following reasons:

• Some people use TXs without ESP-NOW capability and would like the RX to be listening to telemetry coming from the aircraft directly
• It would make the antenna tracker act independently from the transmitter
• It would also allow for using directional antenna on this RX since the antenna tracker is already aiming at the aircraft

[CapnBry]

Would it be possible to use the RF chip of ELRS RX to receive telemetry for this?

Someone could write a completely passive RX that listens for telemetry packets on the air coming from the real RX and puts them back together to get the position data, but that's not what this is at all and has very little in common with it.

[sarahdaviscc]

Is having the RX relay telemetry to a backpack and having it output CRSF possible?

[CapnBry]

Is having the RX relay telemetry to a backpack and having it output CRSF possible?

The RX is relaying telemetry to the backpack and having it output CRSF via ESP-NOW? If you want UART-based telemetry, then it would come from the handset's Telemetry Mirror option.

[LouisRegnierCS]

Hi ! Thank you so much for the work on this AAT, it seems really great !

I want to use it but I'm strugling with the setup. I have an ESP8266 (12F) on which I have flashed the "DIY Automatic Antenna Tracker Backpack" target. I have also flashed my TX backpack with the same bind phrase so I was expecting everything to work.
However it doesn't seem to create a wifi when I press the button on GPIO0, or when I enable the VRX wifi from the lua script on my TX, and it also doesn't display anything on the I2C Screen so I'm not sure that it actually flashed correctly...
Everything seemed fine when I flashed over UART, it wrote success so I was feeling confident.
Also the led that indicates a reset of the ESP keeps blinking every 20s or so, which I'm guessing isn't great news...

I am sorry to bother you on this pull request, but I'm out of ideas to solve my issue.
If you could point my in the right direction I would greatly appreciate it.
Thanks and have a good day !

[CapnBry]

I don't know, but it seems like if there's nothing that even shows up on the I2C display, that would be the first place I'd start looking for what's going wrong. If it boots, it shows something on the display so until you see that, there's no use trying any other functionality. You could verify that the screen's I2C address is set to 0x3C and that it is a SSD1306 128x64. If that's good then you're either not flashing the firmware in a way that it works, or your wiring is wrong. Disconnect the button and the servos until you get this part working.

This isn't really a tech support forum so this is the extent of the help I'll provide.