the default pitot order of 2 (which mean automatic) works well, but the best setup is to work out which order your pitot is really in and set 0 or 1. To do that try 0 and see if you get airspeed when you blow into the pitot. If not then change to 1.
2 Likes
Thank you for your response tridge.
the above airspeed sensor I am using it on my Plane.
As you suggested I set the ARSPD_TUBE_ORDER = 0 which top port of the airspeed sensor detecting the value when blow and when set ARSPD_TUBE_ORDER = 1 it works bottom port of the sensor. how to identify in the sensor that which one is static port and which one is dynamic port.
here I have an doubt that its any particular port of the sensor connect to pitot tube or can i connect any port with any pitot tube?
You could determine this empirically if you don’t have the information on how to connect the pitot-static tube from the sensor manufacturer.
Connect a length of tube to each of the ports on the sensor. Connect the sensor to the flight computer. Using mission planner or other software you should be able to measure the airspeed indication. It will be approximately zero on the bench. If you blow into either of the two tubes, blowing in one will produce a positive airspeed and the other probably no effect or negative. The tube that gives a positive airspeed is connected to be connected to the pitot-static sensor dynamic port, which is the pipe that is straight in line. The other tube connects to the static port which is the pipe coming off the side at an angle.
So from what you said earlier upthread, the bottom port will connect to the dynamic port (straight) and the top port will connect to the static port (side). You can confirm by blowing on the tip of the pitot-static tube directly. You should get a positive ASI.
@cambull Thank you for your support.
As you said if i configure ARSPD_TUBE_ORDER = 2 and it will work definitely, but my concern is is to use only one tube order (due to lag of space availability in the plane) for that i am thinking to place one tube straight single iron tube with 3mm inner diameter (NO static and dynamic port on that tube).
will this work with single tube order reliably?
Depending on where you take your static port pressure from it might or might not work. Just having the static port inside the airframe, rather than connected to the pitot-static sensor, any change in internal pressure due to airflow over the airframe will affect the airspeed reading. Personally I would not take the risk and route the second tube to the sensor directly. I would be concerned about unpredictable behaviour having the static port internally. YMMV.
Struggling with ground steering and takeoff:
Having a hard time tuning my ground steering PIDs for auto takeoff.
In UAVlogviewer you can clearly see a turn in wrong direction an no straight line at all.
Tried out countless options and failed:
- second compass (compasses did alway show me offset in direction until I tried “autolearn” during flight)
- different servo
- aggressive and low PIDs and of course default/suggested PIDs
- Taildragger settings (negative pitch for tricycle)
Pls find my logs here:
Thanks in advance for giving me hints.
BR Guido
@tridge
If I connect the camera to FC, the video for OSD is switched to PAL, but when I do not connect the camera, video is in NTSC mode and I do not see the whole OSD text (3 vertical charts are missing).
Please, is there any option to not use an auto-switch between PAL and NTSC and keep only fixed PAL video setting?
what sort of camera? what flight controller? parameter file?
The camera is Hawkeye Firefly Q6, FC is Matek F765-WING.Parametre_Nimbus 1800.param (20.1 KB)
Edit: Problem with NTSC is only if I do not connect the camera at all during FC operation. Then it remains in NTSC. When I am connecting the camera during operation and then I unplug it, it remains in PAL - this is OK.
I don’t think this is expected behaviour?
Plane 4.1: Auto mode selected, planned mission completes as expected and the plane RTL’s - all good so far.
I tried to re-start the mission using RC switch option (selected flight mode is still Auto). Mission planner acknowledges the mission reset, and reports heading to WP1 (as expected). But the plane remains in RTL 
The only way to exit RTL appears to be to change modes, then when Auto is selected again, the mission re-starts.
I don’t think this is expected behaviour, as MP clearly says heading to WP1, but remains in RTL.
I have not tried this with previous firmware versions… any thoughts?
That is deliberate. It allows the GCS operator to change what waypoint the mission will start in. For example, if I bring a plane out of AUTO while still flying, I often want to set which WP it will start on when I bring it back into AUTO, so it skips takeoff and goes to the location I want.
This is why the reporting to the GCS of what WP is “current” is separated from what mode you are in.
Hi Tridge
Thank you - understand - like most things once you understand the logic / behavior, it is not an issue…
2 Likes
Due to space constrain I’m not planning to set ARSPD_TUBE_ORDER =2.
As per @tridge advice on tube ordering ( ARSPD_ TUBE_ ORDER =0 or 1.) Arduplane takes airspeed value only either top port or bottom Port of the airspeed sensor based on above value.
So if I set either of the value it will not affect other one .if I set ARSPD_TUBE_ORDER =2 would make change in internal pressure if leave without tube inside the frame.
The problem with only using one tube on the airspeed sensor is that the other unused input to the sensor still senses the pressure inside the airframe and subtracts that from the pressure at the dynamic port. The pressure sensor is a differential sensor and does not measure absolute pressure. Any variation on the internal pressure will affect the measured airspeed. Personally I would connect both pressure ports to the pitot-static tube. Behaviour would be much more predictable IMHO.
1 Like
Hello!
Is it possible to have two receivers for diversity?
If yes, please any links.
I’m using crsf protocol.
Regards.
TBS Diversity Receiver 1 or TBS Diversity Receiver 2
Maybe not what you want to read, but diversity. ArduPilot is not responsible for the diversity of 2 separate receivers, even if you could technically connect it.