Thank you Eric, I made a little flight yesterday with rangefinder activated with orientation set to 0 (front)
Hi Christian
I tested using this log this morning, and I can see there are no range messages type #173 in your TLog.
Click here and find (Ctrl/f) “#173”
The FC is not sending this Mavlink message type, so range will always be zero when it is sent through to Yaapu’s LUA script on the Tranis/Horus.
I don’t know much about rangefinders, but found these links:
https://ardupilot.org/copter/docs/common-rangefinder-landingpage.html
https://ardupilot.org/plane/docs/common-rangefinder-setup.html
If you use Mav2PT, you could compile with these options in config.h, and all the instances of message #173 it finds coming from the FC should print to the Log.
#define Mav_Debug_Range // #173
#define Frs_Debug_AttiRange // 0x5006
Regards
Eric
Thank you for putting this together, Eric! This is big help on a Linux board with serial ports that have a hard time keeping up with S.Port.
I wonder if it’s possible to create the opposite translation, where the firmware would listen for incoming S.Bus data from the RX and output MAVLink RC_CHANNELS_OVERRIDE or equivalent. Again, this is in the context of ArduPilot running on a Linux computer without realtime IO.
Hi Ari
I’m glad you are getting some value out of the project, and nice to hear about your Linux board. Yes, I did hack something together a couple of years ago for FrSky to Mavlink, but I never really fully tested it. One issue is that is not bi-directional, so a request from the GCS to the FC for (say) parameters will be ignored. This deficiency can be fixed if I ever get enough time.
The project is here
There is also an SBus project on my github, which could maybe be incorporated.
Thank you for the link, Eric. Oh, that’s a much more ambitious project. I’m thinking of much simpler firmware: it reads S.Bus on one end and spits out one MAVLink message, RC_CHANNELS_OVERRIDE. No telemetry in this direction, only control.
BTW, I see that you used to support STM32 but dropped support. I’m curious what was lacking in F103.
I’m thinking of much simpler firmware: it reads S.Bus on one end and spits out one MAVLink message,
RC_CHANNELS_OVERRIDE. No telemetry in this direction, only control.
That should be quite easy to do Ari. My FrSkyPort class already decodes SBUS (from F.Port), so it’s mostly a matter of taking a lot of code out of mav2pt.
I stopped supporting STM32F103 variants because the emphasis shifted to WiFi/BT i/o and the added complexity of keeping the code in step. Some variants were a little tight on memory.
1 Like
Ari, here is a quick SBUS to RC hack for you to try. You will also find it on my GitHub under SBUS tools.
I’ll be in the bush for the next few days, but should still have internet.
Thank you! The Teensy should be here today. I should be able to test as soon as it arrives.
So I looked at the ZIP and I’m not sure what I’m looking at. Can you elaborate?
You asked about SBUS to Mavlink RC Override.
The code decodes SBUS into 16 x PWM channels and pushes them to Mavlink #70 RC Override. It first checks for good Mavlink heartbeat and good SBUS.
The zip includes the SBUS class library.
You would need to tweak it, like choosing baud rate for Mavlink.
There are some #define debug statements you can use or comment out.
Thank you, Eric! I saw the S.Bus decode code there, but missed the RC override.
First, I’m trying to set up the basics. I received the Teensy 3.2 yesterday. I’m getting MAVLink in (LED is solid) but no S.Port out.
The traces show MAVlink going in, and s.port queries from the RC receiver, but I can’t see telemetry coming out of the Teensy.
I have #define FrSky_Port_Type 1 and #define Air_Mode in config.h.
That all looks ok Ari. Mav2PT needs to read frsky telemetry from the receiver, simply to find the right time to inject its own packets.
You could look at the FrSky debug options, and make sure you are getting data from the receiver on the S.Port. Remember, it’s one wire inverted.
Thank you, Eric. I took the s.port trace (red, #02) at Teensy pin 1. It’s inverted.
There are many debug macros. I’m not sure which ones I should use, or what they do. These two seem to have names that may be relevant: Debug_FrPort_Stream and Debug_Mavlite_SPort. Can you clarify which ones I should use?
Try Debug_FrPort_Stream
If I uncomment #define Debug_FrPort_Stream, I get compile errors:
"C:\\Program Files (x86)\\Arduino\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g Wall -ffunction-sections -fdata-sections -nostdlib -MMD -fno-exceptions -fpermissive -felide-constructors -std=gnu++14 -Wno-error=narrowing -fno-rtti -mthumb -mcpu=cortex-m4 -fsingle-precision-constant -D__MK20DX256__ -DTEENSYDUINO=153 -DARDUINO=10813 -DARDUINO_TEENSY32 -DF_CPU=96000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\akrupnik\\AppData\\Local\\Temp\\arduino_build_73353/pch" "-IC:\\Program Files (x86)\\Arduino\\hardware\\teensy\\avr\\cores\\teensy3" "-I\\\\muavfs01\\UserDocs$\\akrupnik\\Documents\\Arduino\\libraries\\CircularBuffer-master" "-I\\\\muavfs01\\UserDocs$\\akrupnik\\Documents\\Arduino\\libraries\\c_library_v2" "-IC:\\Program Files (x86)\\Arduino\\hardware\\teensy\\avr\\libraries\\SPI" "-I\\\\muavfs01\\UserDocs$\\akrupnik\\Documents\\Arduino\\libraries\\Adafruit_GFX_Library" "-I\\\\muavfs01\\UserDocs$\\akrupnik\\Documents\\Arduino\\libraries\\Adafruit_SSD1306" "-IC:\\Program Files (x86)\\Arduino\\hardware\\teensy\\avr\\libraries\\Wire" "C:\\Users\\akrupnik\\AppData\\Local\\Temp\\arduino_build_73353\\sketch\\MavToPass_v2.63.9.ino.cpp" -o "C:\\Users\\akrupnik\\AppData\\Local\\Temp\\arduino_build_73353\\sketch\\MavToPass_v2.63.9.ino.cpp.o"
In file included from
C:\Users\akrupnik\MavlinkToPassthru\MavToPass_v2.63.9\MavToPass_v2.63.9.ino:145:0:
C:\Users\akrupnik\AppData\Local\Temp\arduino_build_73353\sketch\FrSky_Ports.h: In member function 'byte FrSkyPort::ReadByte()':
FrSky_Ports.h:599: error: 'Printbyte' is not a member of 'FrSkyPort'
FrSkyPort::Printbyte(b, '<');
It looks like Printbyte was a member of FrSkyPort at some point, but is a standalone function now. I fixed the error by replacing FrSkyPort::Printbyte(b, '<'); with Printbyte(b, 0, '<');
Regardless of the value of the flag, I get this on the serial monitor:
Starting MavToPass_v2.63.9 .....
Display support activated: Landscape
64x128 TEXT_SIZE=1 CHAR_W_PX=6 CHAR_H_PX=8 SCR_H_CH=8 SCR_W_CH=21
S.Port selected
Air Mode selected
Battery_mAh_Source = 3 - Define battery capacities in the LUA script
RSSI Override for testing = 70%
Target Board is Teensy 3.x
Mavlink Serial In
MavLite supported
No WiFi options selected, WiFi support not compiled in
No Bluetooth options selected, BT support not compiled in
Mavlink serial on pins rx = 9 and tx = 10
S.Port at 57600 baud is INVERTED and 1-wire half-duplex on Teensy3.x pin 1
hb_count=1
hb_count=2
hb_count=3
Mavlink good!
FrPort scheduler buffer full. Check FrPort Uplink to GCSAri,
We are looking for two bytes from the receiver, then we inject our translated packet. The code is in this function:
void FrSkyPort::SPort_Read_And_Write(uint8_t *buf)
if ((prevbyt == 0x7E) && (byt == 0x1B)) { // Real-Time DIY downlink slot found, slot ours in, and send right now
FrSkyPort::frGood = true;
FrSkyPort::frGood_millis = millis();
inject_delay = micros();
FrSkyPort::InjectFrame(); // Interleave a packet right now!
return;
}
See if you can find that byte combination on your logic analyser, coming from the receiver.
However, it looks like the Teensy is not reading on pin 1. The Serial monitor should show a flood of telemetry in.
I have seen more than a few cases where pin 1 on the Teensy is damaged by static. I’m afraid they are particularly fragile, so be sure to take ESD precautions. If your pin 1 is blown, the good news is that you can use serial3, pin 8 instead. I have needed to do this more times than I care to admit.
#if defined TEENSY3X // Teensy3x
#define Teensy_One_Wire // default half-duplex
#define MavStatusLed 13
#define InvertMavLed false
#define BufStatusLed 14
#define mav_rxPin 9
#define mav_txPin 10
#define frPort_Serial 1 // Teensy F/SPort port1=pin1, port3=pin8.
change to
#define frPort_Serial 3
and then use pin 8
Also, if you don’t need display support, comment out this line a few lines lower in config.h
#define displaySupport // un-comment for displaySupport
EDIT: You might also want to un-comment this line. Mavlite is experimental:
#define MavLite_Support
Aha! Switching to pin 8 did the trick! Now I’m getting telemetry on my Taranis! I’m also getting a flood of 7E prints on the serial console like you’re saying.
Thank you, Eric!
displaySupport is commented out by default in the source.
What is MavLite?
Mavlite is a half-duplex (bi-directional) frsky telemetry protocol proposed and implemented by Alex. He has implemented it in ardupilot now, and also the LUA side on the Taranis/Horus, with the objective of giving them mini GCS capability.
I’m working on implementing Mavlite in Mav2PT for long-range radios, but got a little diverted onto other things for a while. Made some progress today, so …
So it’s a different protocol on the ArudPilot side, not 1, 2 or 10, but some other number?