Cube2.1 Quadcopter with Telemetry module on Serial 1, Flir Vue Pro on serial2 with SR_Position only set on 5 and Benewake TFmini on serial4.
Tested Mavproxy on Linux and Windows and i was getting Mode 0x00000040 all the time, which after alot of TAE i managed o make it go away in the following manner.
I realized that it was noise from another serial and starting i set all besides serial1 to -1, the problem went away and worked my self all the way to find out that Serial2 (FLIR) is causing this noise.
Is there some way to cancel this out?
On master you can use SERIALn_OPTION to mark the channel as “private”. No
traffic from that serial port will be forwarded to other mavlink
connections after that - so it better be ArduPilot consuming those
messages from that point on.
Otherwise we’d have to look at why pymavliunk isn’t already filtering
those messages out - there’s a function “looks like autopilot heartbeat”
or something which we use for filtering various of these messages.
Peter
@peterbarker Thank you for your reply. It never crossed my mind to check Serialn_OPTION to 10. i will test and keep you posted
@peterbarker due to really bad weather i was able to test only today.
Tested Serial2_Option 10 and the problem is still here.
My next test it to connect only the FC Tx to Flir Rx and see if i get the problem, then if i can trigger and last if i get geotags.
@peterbarker for the last hour i tested (always with reboot) all settings from 1-10 and also tested to disconnect the TX (flir)/RX(FC) from the camera to see if the problem is there and i get geotags.
I dont need to go outside since within the workbench area i have a GPS repeater and i get 3ddgps on my bench. if all cables from flir to mavlink are connected i get the issue, no matter the setting. If i disconnect the cable i stop having the issue but i no longer get geotags.
In order to make sure, i tested once TX and once RX. on both occasions, behavior was the same.
Edit****: Tested an hour more and found that with my flir Tx disconnected i was wrong to say i dont have geotags, but i was true when i said i keep having the 0x00000040 message on mavproxy. I can see on MP that the camera is found on my telemetry serial, which means that 99% is some heartbeat that the FC resends to mavproxy.
Any ideas on how to clear this or simply make the camera unable to be seen on my serial?Ioannina 4.0.4 Paramaters.param (18.4 KB)
Could you provide a mavproxy .tlog showing the problem, please?
@peterbarker Hello and thank you for all your assistance.
I just boot everything and after allowing run for a while and show the “problem” on my screen i took all the logs for your to inspect.
mav_logs.zip (428.8 KB)
OK, so there are three heartbeat sources in the log:
2020-09-22 16:26:26.74: HEARTBEAT (id=0) (link=None) (signed=False) (seq=146) (src=1/1)
type: 2 (MAV_TYPE_QUADROTOR)
autopilot: 3 (MAV_AUTOPILOT_ARDUPILOTMEGA)
base_mode: 81
MAV_MODE_FLAG_CUSTOM_MODE_ENABLED
! MAV_MODE_FLAG_TEST_ENABLED
! MAV_MODE_FLAG_AUTO_ENABLED
! MAV_MODE_FLAG_GUIDED_ENABLED
MAV_MODE_FLAG_STABILIZE_ENABLED
! MAV_MODE_FLAG_HIL_ENABLED
MAV_MODE_FLAG_MANUAL_INPUT_ENABLED
! MAV_MODE_FLAG_SAFETY_ARMED
custom_mode: 0
system_status: 3 (MAV_STATE_STANDBY)
mavlink_version: 3
2020-09-22 16:26:26.74: HEARTBEAT (id=0) (link=None) (signed=False) (seq=0) (src=1/100)
type: 0 (MAV_TYPE_GENERIC)
autopilot: 8 (MAV_AUTOPILOT_INVALID)
base_mode: 64
! MAV_MODE_FLAG_CUSTOM_MODE_ENABLED
! MAV_MODE_FLAG_TEST_ENABLED
! MAV_MODE_FLAG_AUTO_ENABLED
! MAV_MODE_FLAG_GUIDED_ENABLED
! MAV_MODE_FLAG_STABILIZE_ENABLED
! MAV_MODE_FLAG_HIL_ENABLED
MAV_MODE_FLAG_MANUAL_INPUT_ENABLED
! MAV_MODE_FLAG_SAFETY_ARMED
custom_mode: 0
system_status: 4 (MAV_STATE_ACTIVE)
mavlink_version: 3
2020-09-22 16:26:27.13: HEARTBEAT (id=0) (link=None) (signed=False) (seq=14) (src=255/230)
type: 6 (MAV_TYPE_GCS)
autopilot: 8 (MAV_AUTOPILOT_INVALID)
base_mode: 0
! MAV_MODE_FLAG_CUSTOM_MODE_ENABLED
! MAV_MODE_FLAG_TEST_ENABLED
! MAV_MODE_FLAG_AUTO_ENABLED
! MAV_MODE_FLAG_GUIDED_ENABLED
! MAV_MODE_FLAG_STABILIZE_ENABLED
! MAV_MODE_FLAG_HIL_ENABLED
! MAV_MODE_FLAG_MANUAL_INPUT_ENABLED
! MAV_MODE_FLAG_SAFETY_ARMED
custom_mode: 0
system_status: 0 (MAV_STATE_UNINIT)
mavlink_version: 3
The first is the autopilot.
The second is the camera.
The third is MAVProxy.
What value where you setting the SERIALn_OPTION to to disable mavlink forwarding?
On my Serial2 which the camera is connected at the moment of this test i had Zero. I tested 10 as suggested by you and problem was still there. When i disable serial2 then the problem stops.
At some point i decided to test all values from 0-10 just to see if i could get it to go away but it never stopped.
***Edit: Reading the latest arducopter Flir wiki, it states that if the camera is properly connected you will see it on your MP and no matter the setting i was always able to see it there.
On my Serial2 which the camera is connected at the moment of this test i had Zero. I tested 10 as suggested by you and problem was still there. When i
disable serial2 then the problem stops.
At some point i decided to test all values from 0-10 just to see if i could get it to go away but it never stopped.
You are not after a value of 10. You are after a value of 1024 (1<<10)
@peterbarker It seems i am missing something.
If i understand correct, you want me to insert on serial2_options a value of 1024?
Again i say: If i understood correct, i can say i tested it on both serial2 and serial1 and my outcome was the same. Here are the MavProxy tlogsmav2.zip (332.0 KB) mav3.zip (874.6 KB)
On file Mav2 i had serial2 to 1024 and on file Mav3 i had serial one which is the communication link for mavproxy.
Yes to set the 10th bit to 1, you need to write 1024 into the parameter value.
@amilcarlucas as I said above I already added 1024 value on serial2_option without any change on my mavproxy results. On my above tlog you can see both the value and the camera information persisting to appear. I also checked my cam passthrough and in the morning I will test to also shut passthrough1 in case it helps
Any ideas? Last couple of days i tested cable configurations, other serial ports, all possible settings but still it remains
@peterbarker could it be possible that serial 2 is simply communicating with serial 1 no matter what and I get this “error” which makes it impossible for me to use mavproxy?
Is there I way I can filter it out on the mavproxy side?
There must be a 4th source of heartbeat sending on sysid 1 compid 1, or Mavproxy would be filtering the mode message. Or mavproxy is not filtering by comp id
source is the Flir Camera
@MerkaTony that option bit I mentioned is only available on master - please try master and see if that fixes your problem.
If running master permanently is not an option then putting a change into pymavlink (https://github.com/ArduPilot/pymavlink/blob/master/mavutil.py#L333) would make your problems go away.
Hi,
I hope you’ve found a solution. I had a similar setup on my copter with Herelink connected to Telemetry1 port on the Pixhawk board and RDF 900 connected to Telemetry2 port. The Herelink handled air-to-ground communication, while the RDF900 managed communication between air and ground units which was connected to a Raspberry Pi 4 on the ground sending dronekit commands via telemetry.
Initially, I tested this Raspberry Pi setup with a Skydroid transmitter and receiver, successfully sending DroneKit commands via the Skydroid transmitter to the drone without any errors. However, when I tried the same setup with Herelink, I encountered an exception error message saying “message (0,0) mode not available.” Interestingly, despite the error, the code executed successfully.
To address this, I made changes to the autopilot parameters:
- For Herelink:
Serial1_baud=115,serial1_protocol=2,serial1_option=1024,serial1_pass=-1(disabled). - For RDF900:
Serial2_baud=57,serial2_protocol=1,serial2_option=0,serial2_pass=-1(disabled).
After making these adjustments, there are no errors on the terminal, and the system runs smoothly. when ever i removed herelink the error used to dissapear which means that pixhawk was not able to handle two data streams simultaneously on the same line and so commands from rpi ( dronekit) and herelink commands were not with similar message format.
i had rpi on ground as i had4 drones controlled over telemetry from this pi .