I know how to change panels from flight mode in the "change panel" drop down in the minim config software.
But I tried selecting chnl 7 from my tx to change panels and minim osd isn't acknowledging it. How does minim know what the channel values are? There is no servo plug into it. I assume it must be in the form of a mavlink command.
What to be done to get this to work?
Replies
I captured the data on the Rx line of the OSD, and I have found the RC_CHANNELS messages sent by the Ardupilot (system 01, component 01) regularly:
Radio turned off:
FS LN SQ SS SC MI TS32LH RCLH1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 CC RS CSLH
fe 2a 26 01 01 41 0e280000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00 00 678c
Radio turned on:
fe 2a 1f 01 01 41 961a0000 db05 da05 2e04 da05 9106 2b06 2904 2904 2904 db05 db05 db05 ea05 ea05 ea05 ea05 0000 0000 10 00 3d0c
(This is a 12ch radio, so the last 4 0x05ea are made up by the Ardupilot, I guess...)
FS - Frame start marker
LN - Payload length (bytes between message id and checksum)
SQ - Frame sequence number
SS - Sender system ID
SC - Sender component ID
MI - Message ID
TSLH - Timestamp (since bootup), low byte first
RCLH - Channel value, low byte first
CC - Number of channels (channel count)
RS - RSSI (system dependent value) (255 - unknown)
CSLH - Checksum (CRC, actually), low byte first
Interesting addendum: the time diff between such two messages are exactly 0x1f4 (500). Since the frequency requested was 0x0002 (Hz), this means that the
values correctly reported twice per second as requested and the timestamp value is in millisecs.
Since it is reported using 32 bits, one MUST have to restart its copter/plane autopilot after every 49 days of continuos operation or else it might fail
even during mid-flight! (Copyright by Matt Parker. ;) )
If anyone is interested in CRC:
Checksum is a CRC-16/MCRF4XX value, always computed from all bytes except the frame start marker. Also, one extra byte salt appended at the end.
The salt is an individual (not unique, but constant) value for all message types. The value is generated from the official message name by a specified algorhythm.
Pre-generated values can be looked up from arrays present in all kind of implementation available.
Here is the C one: https://github.com/mavlink/c_library_v1/blob/master/common/common.h (look for the MAVLINK_MESSAGE_CRCS array)
The message ID in our case is 0x41 = 65, so look up the 66th element in this array.
(Message id numbering starts with 0, so the 1st array element belongs to message #0, the 2nd element to message #1, and so on...)
I help you, the 66th value is 118 = 0x76.
So if you upload for example 2a260101410e280000000000000000000000000000000000000000000000000000000000000000000000000000000076 to
https://crccalc.com/ and select hex as the input type,
you will actually get 0x8C67 in the CRC-16/MCRF4XX row if you click on the "Calc CRC-16" button, and that is not a coincidence! :)
The REQUEST_DATA_STREAM(#66) message stream_ids the OSD sends:
stream_id messages associated
01 - raw sensors: IMU_RAW(#26), GPS_RAW(#24), GPS_STATUS(#25)
02 - extended status: GPS_STATUS(#25), CONTROL_STATUS(?), AUX_STATUS(?)
03 - rc channels: RC_CHANNELS_SCALED(#34), RC_CHANNELS_RAW(#35), SERVO_OUTPUT_RAW(#36)
06 - LOCAL_POSITION(#32,#64,#89), GLOBAL_POSITION/GLOBAL_POSITION_INT(#24,#33,#63)
0a - autopilot dependent
0b - autopilot dependent
0c - autopilot dependent
Distinct messages required (excerpt of above):
#24 0x18
#25 0x19
#26 0x1a
#32 0x20
#33 0x21
#34 0x22
#35 0x23
#36 0x24
#63 0x3f
#64 0x40
#89 0x59
As it turned out, the Ardupilot sends a bunch of mesages by default, not just the heartbeat.
The rate of those messages can be set: http://ardupilot.org/copter/_images/mp_telemetry_rate.png
Messages sent by Ardupilot on its own (without request, captured during ~20sec period):
0x00 - HEARTBEAT
0x01 -
0x18 - GPS_RAW (needed by OSD)
0x1b
0x1d
0x1e
0x21 - GLOBAL_POSITION_INT (needed by OSD)
0x23 - RC_CHANNELS_RAW (needed by OSD)
0x24 - SERVO_OUTPUT_RAW (needed by OSD)
0x2a
0x3e
0x41 - RC_CHANNELS
0x4a
0x6f - (sent only once)
0x74 - (sent two times)
0x7d
0x96 - (sent only once)
0x98
0xb2
0xb6
0xfd
Obviously, when OSD's Tx is connected, all the messages belonging to streams required are reported periodically.
RC_CHANNELS_RAW and is one of those messages.
Messages sent by autopilot with OSD connected (captured during ~10sec period):
0x00 - HEARTBEAT
0x01 -
0x02 -
0x16 -
0x18 -
0x1b -
0x1d -
0x1e -
0x21 -
0x23 -
0x24 -
0x2a -
0x3e -
0x41 -
0x4a -
0x6f - (sent only once)
0x74 - (sent only once)
0x7d -
0x84 -
0x93 -
0x96 - (sent only once)
0x98 -
0xa3 -
0xa5 -
0xad -
0xb2 -
0xb6 -
0xc1 -
0xf1 -
0xfd -
0xfe - (sent only once)
Note: There are some messages which are sent once, or a few times only, during the test period.
This indicates that there are some events that triggers the sending of such messages, since one can not provide less than 1Hz period
in a request.
Some off-topic about my personal problem of connecting multiple devices to the same mavlink serial port with an Y cable follows:
I checked what exactly my radio's telemetry module sends and it turned out that it only requires 0x01,0x03,0xa streams,
which are the SUBSET of what the osd module request!
(Although, with slightly different rate settings: 2,2,10(osd) vs 2,5,5(radio), but I can live with that and more importantly, my radio also happy with those rates. :) )
So it turned out I'm lucky, I can share the same telemetry port with my receiver's telemetry and OSD module using a simple custom Y cable, wiring the radio telemetry as a passive "listener" only (radio telemetry Tx not connected).
The other telemetry port on my PixHawk is used for GroundControl communication. (Unfortunately that's all, only two of the 5 serial ports of PixHawk (named TELEM1,TELEM2,GPS,SERIAL4,SERIAL5) can be used for telemetry connection, because Ardupilot allows only two of them to get associated with MAVLINK communication.)
BTW, my configuration:
Autopilot hardware: PixHawk 1. https://docs.px4.io/en/flight_controller/pixhawk.html
Autopilot software: ArduPilot (ArduCopter V3.6.7)
OSD hw: MinimOSD Micro
OSD sw: microminim.ardupilot.multirotor.hex (ver1.9.1.1 - available at https://github.com/ShikOfTheRa/scarab-osd/releases)
Radio telemetry hw: RadioLink's R12DS receiver with a PRM-03 telemetry module
OSD flashed with MW_OSD_GUI software. (There is a link to it on the firmware download site.)
It requires a cheap FTDI hardware available almost everywhere... (https://i0.wp.com/dronesdecarreras.com/wp-content/uploads/2015/10/M...)
(MinimOSD is a good design: one side of it is pin compatible with the FTDI board. You have to care about only not to flip the board accidentally when connecting. :) )
Ardupilot software is flashed into PixHawk with QGroundControl, using a simple USB cable. (One can use MissionPlanner software also,
but I prefer QGroundControl, since it is available on all platforms, even on android. So I can use my mobile phone as ground control and telemetry display
during flight...)
Summary:
- RC CHANNEL data IS sent through Mavlink to OSD. Moreover, it is sent by default, so even if the OSD is connected as a passive device (only its Rx is connected to the Autopilot's Tx), it should be able to react to radio switch changes. (At least mine works perfectly. However I had to configure OSD configurator to use a 3-state switch assigned to channel 10 to change display modes instead of RSSI value possibly reported on channel 8 - which is the default. See attached screenshots.)
- Connecting two mavlink devices to one telemetry port is simple, but only one of them can have its Tx line connected to Autopilot's Rx. Practically the one with the broadest stream request set.
If other streams are required (because the connected devices reuest mutually exclusive streams and/or the defaults sent by the autopilot are not sufficient), there are still alternatives:
- One can take advantage of flow control and build a simple circuit that enables CTS pins of the connected devices one-by one, so only one device will use Tx line at a time. (Unfortunately neither minimOSD, nor PRM-03 does not support flow control. So in my particular case it wasn't an option.)
- Set the missing streams rate in autopilot (through a GroundControl software). See SR1_xxx, SR2_xxx, SR3_xxx parameters at http://ardupilot.org/copter/docs/parameters.html
Thus the autopilot will send them by default.
- Build a complex microcontroller circuitry with some rerasonable amount of ram that acts as an UART router.
It accepst serial data on multiple connections parallel, stores them temporarily and send them in series to autopilot asap. :)
Sorry guys for the long posts, and for the many off-topics, but I thought if someone else finds this topic because he/she has the same question, he/she has the right to get an as detailed answer as possible. Too many info always can be skipped, but slightly not enough usually does not help at all...
Ok, to simplify things, I connected the OSD Tx line to my FTDI's Rx line and dumped the raw serial communication data with my Linux. (Do yourself a favor if you try this: issue an "stty -F /dev/ttyUSB0 57600 raw" command to capture raw serial data. If you dd or cat the tty device data into a file, some bytes will be interpreted as terminal control caracters and the file will contain a mess. :) )
This is the only and entire packet that is sent by the OSD to my Ardupilot.
Here is the result:
As you can see, the third request is the data stream request for stream #3, which is the RC_CHANNELS stream.
https://mavlink.io/en/messages/common.html#MAV_DATA_STREAM_RC_CHANNELS
"fe 06 03 63 63 42 02 00 01 01 03 01 6e 42"
fe - Mavlink 1 frame marker
06 - payload length
03 - sequence number (this is the third packet sent)
63 - sender system id
63 - sender component id
42 - message id (#66 decimal - REQUEST_DATA_STREAM)
02 - requested message rate, L byte
00 - requested message rate, H byte
01 - target system id
01 - target component id
03 - requested data stream id (MAV_DATA_STREAM_RC_CHANNELS)
01 - start_stop (1 to start sending, 0 to stop sending)
6e checksum L byte
42 checksum H byte
(https://mavlink.io/en/guide/serialization.html#v1_packet_format)
I made some measurements today with my logical analyzer and yep, the OSD definitely requests a huge amount data from the autopilot through mavlink.
Resources:
Right after the first heartbeat arrives on the OSD's Rx line (D1) from the autopilot, the OSD sends huge amount of bits on Tx (D0)... The first command is a request for data sream 01, followed by plenty other requests, which I haven't analyzed yet.
https://mavlink.io/en/guide/serialization.html#v1_packet_format
https://mavlink.io/en/messages/common.html#HEARTBEAT (also, see #REQUEST_DATA_STREAM)
Please note, that during mavlink communication, the logical payload data in the spec is REORDERED, bigger structures transmitted first! ( https://mavlink.io/en/guide/serialization.html#field_reordering )
https://github.com/mavlink/c_library_v1/blob/master/common/common.h - for message CRC salts (aka CRC_EXTRA)
https://mavlink.io/en/guide/serialization.html#crc_extra
https://crccalc.com/ - to check the CRC16. Please note, that the CRC-16/MCRF4XX variant is the one that mavlink implementations use - check available python/C sources on the net. (This is Linux's native implementation btw...)
Funny, but message #65 right above #66 in the spec is the "RC_CHANNELS"... :D
Also, during googling I found out, that if a telemetry capable RC receiver is connected to mavlink, it can send channel value status reports... I'm plannig to check this, and also I want to analyze all the messages the OSD sends to autopilot... The latter will be problematic, because my cheap LA is not able to store enough samples. :(
I'm a newbie, but I need the same feature, so I made a little inspection on this topic.
No tests yet, only googling arond...
It seems like that YES, there are mavlink messages for RC input:
https://github.com/mavlink/c_library_v1/blob/master/common/mavlink_...
And according to this article, you have to REQUEST the RC (stick/switch) data from the device (particularly ANY data other than heartbeat):
https://discuss.ardupilot.org/t/arducopter-message-request-api-data...
I think the OSD does that (requests rc channel data - if configured) through it's TX line.
Unfortunately, I have to share the serial port on my Pixhawk with the telemetry radio to communicate with ground control, so I only y-cabled the RX line to OSD. So I'm stuck at this point... (The other serials are also used for other purposes...)
Haven't checked though. (Whether OSD sends anything over it's TX.) But I'm pretty sure it is not a passive "listener" device, otherwise there would be no TX pin on the panel at all to spare some space...
Maybe, if I send that "request rc input data" command through ground control, the OSD could "pick up" the reply messages and react to switches as required. Just a random thought...
If you already have it setup but it isn't working, check that the channel goes high enough. Not sure the number, I think it is either 1500 or 1800.
I am using that also. How does minim osd "see" the channel pwm? is it passed as a mavlink heartbeat? As mentioned earlier, It must be. There is no phyical servo channel input.
Then how do you set up your pixhawk parms. And you do you test / troubleshoot it? I tried the servo tab on the lower part of the flight data screen. Tried all the channels with varying pwms for high and low. No luck. I looked at live data and chnl 7 out was sending 3 different pwm values based on my dx8 switch assigned to channel 7.
I will post some screen shots. I think it is pixhawk parm setup issue not passing heartbeats. I haven't seen any video with a pixhawk and minim osd with a channel switching. I have seen vids on changing panels based on flight modes, but I don't want that.
I currently am having an issue with osd not seeing some heartbeats, so I have some issues to resolve first which might be related. For example, I am not getting any Long and lat data, but am getting battery volts and flight mode. My gps unit was getting bad health going from 0 to 6 sats and back to 0 constantly. We had bad weather today, so hopefully tomorrow I can resolve some of these issues.
Is it true that you have to power the minim osd up later than the pixhawk.
If someone could post some screen shots, that would be great.
This is old as hell but, nobody ever answered it. I understand what you're asking and I'm trying to figure out exactly the same thing. I used ch5, configured ch5 on my Tx, see it in moving in Mission Planner, and set ch5 on my OSD, how it goes from the APM to the OSD I have no idea.
Read this but still does not answer how to diagnose this issue.
https://code.google.com/archive/p/minimosd-extra/wikis/Screen_Chang...
Hi Peter,
Did you manage to get your OSD switching properly? I am also having trouble getting my Minim OSD to switch. It switches fine via Ch. 7 on my TX but won't switch or toggle via the Servo (Ch.7) screen on Mission Planner. Do you have any suggestions for me?
Regards, Julian
Good timing, I JUST had a full feature maiden flight 2 days ago. I broke one of my 3 position switches, so I moved half of the flight modes to another switch, accidentally shared with my OSD switch... and incidentally I saw the OSD change when I changed flight modes, so it indeed worked.
One thing is the feature where minimOSD will revert to screen 1 if there are any failsafes, I think that is a setting in the minimosdxtra software. When I posted this, I think that was preventing the switch because I had the plane disarmed and probably some of the other conditions to allow switching weren't met. Oh yeah, I am using minimosd-extra firmware. here's some good info: http://www.rcgroups.com/forums/showthread.php?t=1817533.
Hi Peter ,
Thanks for your reply. Yes indeed the Failsafe function is what I am having to resort to when flying beyond RC TX range. It is still not ideal as I would like to be able to switch between panels via Mavlink. Some issue between Mavlink and switching of the Telemetry port possibly but not sure yet. By the way, I am also using Minim OSD-Extra.
You sound like you have the multi switch setup to select flight modes. I tried this but found it a bit confusing and thought if I had to hit RTL in a hurry then it might be a problem remembering the switching order. I have reverted to just one three position switch with Manual, FBWA and RTL and select others via Mavlink if needed.
Julian.
-
1
-
2
of 2 Next