Mavlink to Ardupilot Custom Telemetry CRSF translation for Yaapu Telemetry Script #3077
Conversation
1a46aa4 to
247729e
Compare
|
StatusText already works when cherry-pick'ed onto 3.5.3. |
98309e2 to
05b10f9
Compare
The master branch has a different OTA version and will not bind to a 3.x version. It's not to do with the branch name. |
05b10f9 to
9d76ad5
Compare
|
Thanks for clarification, I just saw the name of my branch on the led display and thus assumed it was taken as version. After some trial and error with the first value, endianess, shifting, ... , I think I'll divide the PR between ExpressLRS and Yaapu Script, as there are standard CRSF frames available for the values that Yaapu Script processes. Means the frame grabbing It should be the same amount of work resulting in cleaner design. |
f0d5eb7 to
980dd72
Compare
|
@raul-ortega any update on the performance of your setup? |
Nothing, due to wheather conditions! |
|
Just for the record,
I was able to reproduce the case where Yaapu infinitely cycles
- Motors disarmed
- Motors armed
- Manual Flight Mode (init)
- FBWA Flight Mode (switched)
It happens with APM Planner on Linux but apparently not with other GCS
software. MP on Windows works fine and QGC on Linux also works fine.
I've only seen this with AP4.5.7, not with AP4.6beta, so this maybe one
of the Mavlink fixes in AP.
Steps to reproduce:
- Connect APM Planner via USB while there already is a HOT RC Link with
Mavlink.
- It stops with delay once APM Planner is disconnected, seems to relate
to some message stuffing, maybe even involve the stubborn sender feature.
I'll wireshark it when I find the time.
BR
|
|
I've got a nomad module, a Quad-plane w/XR4 on AP4.6b4+, and quad w/DBR4 on AC4.5.7. Both on K1000. I'm willing to at least ground test this if it will help the cause. Please tell me what Git commit hash to use because I see a few bounced around here and I'm not sure what's best/safest. Or can I just build from the Git pull request? |
|
Hi @Allister779,
if you are familiar with git commands, you can easily build a patched
version for V3.5.3.
Some time ago, I wrote a guide for cli users
https://www.expresslrs.org/software/toolchain-install/#toolchain-setup-advanced-for-linux-users
You just need to use
https://github.com/menschel/ExpressLRS/tree/testing353
i.e.
```
git clone --recursive -b testing353
https://github.com/menschel/ExpressLRS.git
```
This would only require flashing the TX module, leaving everything else
untouched.
The build command for Nomad would be
```
pio run --environment Unified_ESP32_LR1121_TX_via_UART
```
I generally don't recommend working on master but you can use the expert
mode in Configurator and select this PR to build for both TX and RX.
BR
|
|
I'm not familiar with Git commands so I first tried to use the Git Pull Request function in configurator to build for this PR. The build went okay for the nomad, but it wouldn't connect to any of my receivers (I didn't update them). Verified UID, etc. Admittedly didn't fight too long. Next I used the commit hash for your latest commit in the test353 branch (940fb5) and let Configurator build it for me. That seemed to work. Again, only changed the nomad. Good news, at least so far on the bench it's all working! The yaapu script did crash on me once in all the excitment, but it was just the script. The radio and other telem pages still worked fine. Any concerns about flying this configuration? |
|
In general there is no guarantee for anything.
There were reports that the yaapu lua on the big radios (first revision
of TX16S IIRC) has issues but lately after a couple of targeted fixes
(i.e. use of multi-package frames), nobody complained anymore.
I would recommend you fly an auto mission first and just observe the script.
There should be no impact at all on the RC commands as the transmit side
is not touched.
I've been flying the testing353 branch on RM Bandit 868Mhz (200Hz) +
sub250g ZOHD Drift for a many weeks now, typically some AP-beta tests,
many flights for MagFit, Autotune, and even a complete 25min auto mission.
BR
|
|
@Allister779 update EdgeTX to 2.16 and use the DEV version of Yaapu. |
|
Got a chance to finally fly it today. On AC4.6 beta5, and EdgeTX 2.10.6 (Yaapu on Dev). Good: It worked in flight.
If you need any more info let me know. |
|
Today I was finally able to do a test flight and I had exactly the same
problem.
|
|
Are those both TX16S Revision1, i.e. without the "MK II" tag?
It seems to be an MCU resource problem on that radio, maybe some
alternative chip sourcing during the semiconductor crisis / COVID.
Does it only happen on fast RF modes or also on slow modes?
This sequence
"Motors disarmed",
"Motors armed",
"Manual Flight Mode",
<REAL FLIGHT MODE>
seems to occur on some sort of mavlink connection reset but I don't know
where it happens.
BR
|
|
Mine is a Mk1 Max. I can't remember when I got it, but it's got some good miles on it. The sequence was just as you described, except one time rather than saying "Manual Flight Mode" it said "Position Hold". I don't know about the RF Mode. I was less than 40m away each time it happened. When I did look down the only thing I noticed was my dynamic power was still down at 10mw so I'm assuming it was happy with the connection. |
|
I mean the mode that maps to a specific data rate and therefore mavlink
message rate, i.e. K1000, 250HZ etc.
From what I learned while programming the cordic algo, regular
trigonometric math functions like atan2 are expensive.
My suspicion is that things like the home message which are used to
calculate back the current gps position are killing the lua if they are
updated too often.
I'm not saying that Yaapu does a bad job, but maybe the lua toolbox is
not the best for the job.
BR
|
|
Mine was one of the firsts Radiomaster TX16S, without touch screen. This has been working for a long time, without any issues using yaapu lua script, working with CRSF protocol. Now I'm using K1000 and this is the first time I see this issue in the yaapu lua script. This information is irrelevant: In my case I was not using dynamic power, TX was configure at 500mw and Rx at 100mw. SRx params were set by default by Mission Planner. I was flying at a very short distance, no more than 180 meters. Some info about my setup:
|
|
IMO the best way to iterate on the issue is to reduce specific SRx params.
I don't know the defaults but I assume stuff like the EXT_STAT or
POSITION group can be limited to 1Hz for testing. The GPS messages map
into the HOME message that may be the culprit causing expensive
operations in Yaapu.
If the MCU resource issues vanish, we're on the right track.
For the record, mLRS uses a timer based approach and only sends
multi-package frames. It even fakes traffic to prevent the sensor lost
audible message.
I don't have access to timers from the lib section.
I just translate one protocol to the other.
BR
|
|
I was on K1000 as well. Just so I understand, are you in favor of the mLRS approach? |
|
No,
mLRS project has a narrow view on things and they don't want to become
mainstream but remain a niche.
There is also this notion, not to support ESP hardware completely. My RM
Bandit Micro is supported but only as a SiK Radio, so it cannot be used
with a Handset, looks intentionally.
I recognize mLRS has better mavlink message rates and performance,
especially on the 900M band, but their code quality is questionable.
Apart from that until Matek designed a couple of boards, it was a pain
to work with mLRS. It is also largely incompatible with existing ELRS
LORA hardware. If ELRS project would drop the fixed package:telemetry
rate, it would yield equal performance. It is the bottleneck for MAVftp
operations for example.
BR
|
|
Hi menschel. Have you considered adopting an alternative strategy? Perhaps limiting the rate at which position packets are delivered to the handset so that the Yaapu script doesn't have to perform so many calculations.
|
mLRS pre release v1.3.06: full support of RadioMaster Bandit, Bandit Micro, "big" Ranger and BetaFPV 1W Micro ELRS Tx modules Instead, it seems to me that your module now would not work only as SiK. |
This is absolutely something we want to support, but we can't with the packet format in 3.0 - we'll hope to get this possible in 4.0 |
| handset->sendTelemetryToTX((uint8_t *)&crsfbatt); | ||
|
|
||
| // send the batt1 message to Yaapu Telemetry Script | ||
| ap_send_crsf_passthrough_single(0x5003, format_batt1(battery_status.voltages[0], battery_status.current_battery, battery_status.current_consumed)); |
There was a problem hiding this comment.
Just out of curiosity, why are you only passing one cell of battery info out of CRSF? Is this a part of the AP CRSF standard? The Yaapu script I'm using seems to expect all the cells, not just 1
src/lib/MAVLink/MAVLink.cpp
Outdated
| * Helper function to send an ardupilot specific CRSF passthrough frame | ||
| * with a single data item appid is the function that produces the data. | ||
| */ | ||
| static void ap_send_crsf_passthrough_single(uint16_t appid, uint32_t data); |
There was a problem hiding this comment.
Remove unnecessary duplicate line.
src/lib/MAVLink/MAVLink.cpp
Outdated
| * Helper function to send an ardupilot specific CRSF passthrough frame | ||
| * with a text payload. | ||
| */ | ||
| static void ap_send_crsf_passthrough_text(const char *text, uint8_t severity); |
There was a problem hiding this comment.
Remove unnecessary duplicate line.
src/lib/MAVLink/MAVLink.cpp
Outdated
| * Helper function to send an ardupilot specific CRSF passthrough frame | ||
| * with 2 data item appid is the function that produces the data. | ||
| */ | ||
| static void ap_send_crsf_passthrough_multi(uint16_t appid, uint32_t data, uint16_t appid2, uint32_t data2); |
There was a problem hiding this comment.
Remove unnecessary duplicate line.
src/lib/MAVLink/MAVLink.cpp
Outdated
|
|
||
| CRSF::SetHeaderAndCrc((uint8_t *)&crsftext, CRSF_FRAMETYPE_ARDUPILOT_RESP, CRSF_FRAME_SIZE(sizeof(crsftext)), CRSF_ADDRESS_FLIGHT_CONTROLLER); | ||
| handset->sendTelemetryToTX((uint8_t *)&crsftext); | ||
|
|
src/lib/MAVLink/MAVLink.cpp
Outdated
| // send the gps_status message to Yaapu Telemetry Script | ||
| ap_send_crsf_passthrough_single(0x5002, format_gps_status(gps_int.fix_type, gps_int.alt, gps_int.eph, gps_int.satellites_visible)); | ||
|
|
||
|
|
There was a problem hiding this comment.
One blank line is enough
for Yaapu Telemetry Lua script to work. Uses CORDIC algo to calculate bearing and distance to home. Based on Ardupilot Code but reworked to integer operations.
512dd07 to
d37431a
Compare
|
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In src/lib/MAVLink/MAVLink.cpp
<#3077 (comment)>:
> @@ -37,6 +125,9 @@ void convert_mavlink_to_crsf_telem(uint8_t *CRSFinBuffer, uint8_t count, Handset
crsfbatt.p.remaining = battery_status.battery_remaining;
CRSF::SetHeaderAndCrc((uint8_t *)&crsfbatt, CRSF_FRAMETYPE_BATTERY_SENSOR, CRSF_FRAME_SIZE(sizeof(crsf_sensor_battery_t)), CRSF_ADDRESS_CRSF_TRANSMITTER);
handset->sendTelemetryToTX((uint8_t *)&crsfbatt);
+
+ // send the batt1 message to Yaapu Telemetry Script
+ ap_send_crsf_passthrough_single(0x5003, format_batt1(battery_status.voltages[0], battery_status.current_battery, battery_status.current_consumed));
Just out of curiosity, why are you only passing one cell of battery info
out of CRSF? Is this a part of the AP CRSF standard? The Yaapu script
I'm using seems to expect all the cells, not just 1
I'm not aware of any issue with the battery voltage. I just copied the
CRSF value.
There is one caveat though.
The lua uses parameters sent from ardupilot and there is no equivalent
value specified in mavlink protocol for battery capacity.
You may have to use overrides in yaapu config for those to show correct
values.
BR
|
|
***@***.**** approved this pull request.
Applied cosmetic fixes and rebased onto master.
Thank you for the good collaboration.
BR
|
|
This is not on 3.6.0 ((( |
This PR addresses Issue #3074 adding
Mavlink to Ardupilot Custom Telemetry CRSF translation for Yaapu Telemetry Lua script to work.
Tested on a 128x64 BW Radio:
Stuff that needs to be tested:
Known Issue List: