I spent my 3 day long weekend getting the Pixracer to work. For some reason it made me think of the classic Robert Redford movie “3 Days of the Condor”, where a CIA research analyst who “just reads books” had to figure out a complex conspiracy in 3 days.
Ok, so this is not that, but I was under the pump, I really thought it would be easy, I was planning to get the Pixracer wired up and flashed on Saturday, then work on my Sopwith Camel build for the rest of the weekend. It didn’t work out like that.
But, in the end – I got it working, 3 long days later!
I recorded the whole saga, so come along for the ride! (please Subscribe to Tim the Planman on YouTube for updates). These are the links to the videos:
Maybe my problems are partly because I use a Mac. Why is the Mac “second fiddle” for things like this? Mission Planner has no official version available for Mac. The new release (thanks ArduPilot), still has this caveat:
Native MacOS and iOS support is experimental and not recommended for inexperienced users. For MacOS users it is recommended to use Mission Planner for Windows via Boot Camp or Parallels (or equivalent).
It looks horrible, the fonts are too small to be readable on my laptop screen (I put it on an external monitor when I’m at home, but this won’t work in the field)
None of the panes are resizable
It doesn’t seem to be able to flash the Pixracer. I had to use QGroundControl to do this (worked great).
I don’t know why I should have to use BootCamp or Parallels
But my challenges getting it all working were not just about the Mac.
There is a lot of folklore about flight controllers and how to get them to work, and not a lot of useful documentation. Most of the best information came from getting tidbits of information here and there, from various videos from people like Painless360, Joshua Bardwell and Andrew Newton. But even then – I had to pay attention, it was one 2 second soundbite from one of Painless360’s videos that gave me the hint about why the servos didn’t work while I was running the Pixracer off the power from the USB.
That said there is some useful information out there. Here are some useful links:
I’ve set up ArduPlane on a PixRacer R15 in a Bixler 2. You can see the videos “Three days of the Pixracer” on Youtube.
Then I put the PixRacer in a Bixler 2 and created “The Bixinator” and I did my first flight, including having Return to Home fly the Bixinator into a tree. After I rescued it, I completed Arduplane autotuning. I’ve also put a PixHawk (Version 1 – original) into my Bixler – so I’m calling this one the BixHawk.
I’ve flown the Bixinator several times, including several autonomous missions with auto takeoff and auto landing (without flying into any trees). This post has been updated with some of the things I’ve learned. Unfortunately the Bixinator has crashed one too many times and is now officially retired. However the BixHawk (Bixler 1 + PixHawk) is taking over.
Initial Setup
There are a few things you need to do with AutoPilot when you first connect it in a plane. There is also a getting started guild on the ArduPlane wiki that you might fine helpful.
Warnings: Do not put any rates or trimming into the radio. You do this all on the autopilot
Connect the autopilot to the computer using USB
Flash the firmware with the right model, e.g. plane, and latest version
Calibrate the Accelerometer
Calibrate the Compass
Create the model in your transmitter.
Setup inputs and mixes channels including Flight Mode channel.
Plug everything in to the flight controller (not in the plane yet)
Bind the receiver and calibrate the radio
Install the Flight Controller in the model
Calibrate the Surfaces
Maiden flight – FBWA
Autotune
TECS Tuning (initial)
Tune any special parameters such as auto takeoff/landing
Ready for first Autonomous mission
1. Plug it in
The very first thing you need to do is plug the autopilot into the computer. Because I’m not interested in soldering, I have only tried flight controllers that come with the connectors already soldered on the board, so PixRacer, PixHawk and Duraldal. You can do up to step 7 by just plugging the flight controller in with a USB cable
2. Flash the firmware
I use QGroundContol to flash the firmware. It’s very easy.
Click the QG icon at the top left of the main window
Click Vehicle Setup
Click Firmware
Follow the instructions in Red – first unplug the USB cable
Then reconnect the USB cable
Pick your board, and the version of Ardupilot you want (I use Plane and usually the latest Stable version)
Click Ok – it will automatically flash and reboot
If it doesn’t work check your selections. For example I had a problem flashing my PixHawk 1. There are 2 of them listed, so I tried the other one (1M version) and it worked.
3. Calibrate the Accelerometer
You can do this in QGroundControl or Mission Planner. I like QGroundControl for this step.
Click “Sensors:”
Click “Accelerometer”
Click :”Ok” and follow the instructions
4. Calibrate the Compass
If possible do this outside and away from any sources of interference or sheilding. You can do it as part of your initial setup, but I’d recommend you do it again when you are out at the field for your Maiden flight.
5. Create the model in your transmitter
If you are using OpenTX or EdgeTX – use the wizard to create a simple plane. Use the channel order default for your transmitter. Never override it. If you need to change anything later you can do it on the Flight Controller. I like to set up my inputs to represent what I use the sticks for.
6. Create Inputs/Mixes
Warning: Don’t change rates, add expo or add anytrim (or if you have these remove them all). All of this except maybe expo will be done in the Flight Controller later on.
Mode 1: OpenTX will assume Rudder and Elevator on the left stick and Throttle and Ailerons on the right stick.
Mode2: OpenTX will assume Rudder and Elevator on the right stick and Throttle and Ailerons on the left stick.
This actually switches Rudder and Ailerons from the way everyone flies. So what I do is go into the “Inputs” after the wizard creates the model and set the up as Roll, Yaw and Pitch – which is what they actually are – and map them to control surface channels in the Mixes.
Mode 1 sticks
Mode 2 sticks
Input
Channel
Left Left/Righjt
Right Left/Right
Ail -> Roll
Roll -> #1
Left Up/Down
Right Up/Down
Ele -> Ptch
Pitch -> #2
Right Left/Right
Left Left/Right
Rud -> Yaw
Yaw -> #4
Right Up/Down
Left Up/Down
Thr -> Thr
Thr -> #3
Sticks -> Inputs -> Channel maps (OpenTx/EdgeTX)
7. Plug everything in
Connect all the wires. Yes do it all at once. I made the mistake of thinking I could gradually plug a few things in and gradually get things working. It doesn’t work that way. Plug in at least:
Power Management Board into the “power” socket
GPS into the GPS socket and external compass into I2C socket
Buzzer and Safety switch
EPS wifi board in PixRacer or Telemetry radio transmitter (PixHawk)
Receiver SBUS output into RCIN on the flight controller
8. Bind the receiver
You can connected the receiver to the “RCIN” port on your flight controller using SBUS or PPM, and the receiver will be powered by the flight controller. There are other advanced options for connecting the receiver.
Power on the Flight Controller and bind the receiver to the new model on your transmitter.
Binding will depend on your receiver, so I won’t explain it here. You will need to look this up in the instructions/manual for your particular receiver.
Once the receiver is bound, go to the “Radio” tab in QGroundControl – you should see an option to calibrate your radio. If you have this option, it means that the flight controller is connected to the receiver and it is bound. If you don’t see this then you have a problem. Either your receiver isn’t bound or the connection isn’t good. e.g. WIth FlySky receivers you need to make sure to select “PPM/SBUS” when binding to make sure to get an SBUS output. There are many other possible issues here – google is your friend.
9. Install in the model
Now it’s time to put the flight controller and receiver into the model. When you do this connect the servos to the flight controller.
On a PixHawk1 this will be: Ailerons into Output#1, Elevator into Output #2, Throttle into Output #3 and Rudder into Output# 4
10. Calibrate the surfaces
This is a procedure all to itself. I have a YouTube video specifically about this process and there is a very good page on the ArduPlane wiki that explains it very well.
In a nutshell – set up the control directions and rates on the Flight Controller, not on the transmitter.
It’s time to maiden the plane. This will be a flight in FBWA mode but fully controlled by you using your transmitter. The most important thing to get out of this flight is the logs. You will use the logs to do further tuning, especially TECS tuning.
12. Autotune
If the maiden went ok. it’s time to autotune. There is lots of information and videos about this step. Its actually pretty simple.
Takeoff in FBWA and fly to a comfortable “3 mistakes” height.
Switch to Autodune mode
slowly move the aileron/roll stick left and right (about 2 seconds from end to end) and back as you fly in a straight line. Do this about 20 times.
Slowly move the elevator/pitch stick up and down ( about 2 seconds from end to 3nd) and back as you fly in a straight line. Do this about 20 times.
Fly for at least another 15 or 20 seconds in autotune.
Switch to FBWA mode. You should notice the plane flies much better than before.
Bring the plane in to land
13. Auto Takeoff/landing
Next you can tune for auto takeoff and landing. This will be different if you have a plane with wheels or something like a wing or Bixler style (which I have) that takes off by throwing the plane.
13.1 Bixler/Wing style – no wheels
TKOFF_THR_MAX – max throttle for takeoff. On my Bixler 90% is good, so I’m using that.
TKOFF_THR_MINACC – Minimum acceleration for hand launches. 15 is recommended – I’m sticking with the recommendation.
TKOFF_THR_DELAY – a bit of a problem on the Bixler, change to 1 (from default 2).
TKOFF_THR_MINSPD – using the recommended 4 m/s for hand launch.
TKOFF_ALT – altitude to get to after takeoff. I takeoff over the edge of a hill, so 20m doesn’t sound like much, but will actually be close to 50m above the ground by then.
TKOFF_DIST – The distance from the takeoff where the plane will loiter. Set to 100m because of my small flying field.
TKOFF_PITCH – Default is 15 degrees – this is good.
TECS_PITCH_MAX – setting to the recommended 20 degrees, although on the Bixinator I think that might be a bit of a struggle for it, but the BixHawk will handle it no problem.
13.2 Normal plane with wheels
I haven’t done this yet – follow the Ardupilot Wiki.
14. TECS Tuning
When I first started setting up my first ArduPlane model I didn’t even know this is a thing. It’s a thing!
Actually there are several tuning step s required. You can find them documented in detail on the Arduplane wiki. You will need to do some flights
Setting Parameters
The ArduPlane auto-takeoff and auto-land wiki pages are extremely good and you might find it just as helpful to go and read them. I’m just going to include here the things that are relevant to the Bixinator and BixHawk.
Takeoff
Flight
WP_LOITER_RAD – The Radius of a Loiter. The default is 50m which is a bit too wide for my small flying field, so I’m setting it to -40 (negative is counter clockwise).
ALT_HOLD_RTL – the altitude for RTL. Be very careful with this – it’s set in cm (yes centimetres) very strange, and easy to screw up. 50 meters is 5000cm!
RTL_RADIUS – The radius of the “loiter” at home. If not set it uses WP_LOITER_RAD – so I’m going to set it to zero.
WP_RADIUS – How close to a waypoint the plane needs to get to consider it ‘done’. On my small field the default of 90 m is a bit ridiculous. I’d probably want to make it 10m, but until I understand this better, setting it to 25m.
Landing
LAND_FLARE_ALT – 3 meters – going with the default.
LAND_FLARE_SEC – 3 seconds – just a guess (I have no LIDAR)
LAND_PITCH_CD – no change, default to 0.
TECS_LAND_ARSPD – not used (left at default -1) because I don’t have an airspeed sensor.
TECS_LAND_THR – no airspeed sensor but not really clear what this should be so leaving the default of -1.
TECS_LAND_SPDWGT – set to -1 the “special” recommended value for a dynamically adjusted landing (WGT=height? weird)
Loading Terrain
its a manual process because of no network at the field. Neither Mission Planner, not QGround Control want to download terrain if there is no GPS. I live in a a concrete building so I don’t have a GPS lock when I’m setting up the plane, so I had to download the Terrain manually and load the files onto the SD Card /TERRAIN folder manually. Surely there is a better way? (apparently not).
Creating the Mission in Mission Planner or QGroundControl
I’m still using both Mission Planner and QGroundControl. QGroundControl is best for flashing new firmware. It’s simple and clear and “just works”, The UI in Mission Planner is horrible, but it has everything if you can find it or if you can read it. I do a lot of squinting while using Mission Planner.
This is the mission in a nutshell
NAV_TAKEOFF – to takeoff facing North ( usually the wind is from the North) at 15 degrees to 20 meters.
LOITER_ALT – to move away from the trees (there are a lot of trees around) and gain some altitude targeting 50m.
a simple elliptical flight path of WAYPOINTs around the field s maintaining 50m altitude, just to see how it works.
LOITER_ALT – to lose altitude in preparation for landing
START_LAND
LAND
That’s it. I’ll have my finger by the FBWA button the whole way – wish me luck!
I’m not really sure why I was drawn to this model, but I really do find it quite appealing. I think the model is based on the real world Tecnam P2006T – at least to me it looks like it. The shape of the nacelles, the sleek nose and the shape of the tail really nail it. It’s a beautiful plane.
But by directly copying the ‘real plane’ it seems that SonicModell got themselves in trouble. There are a lot of videos out there documenting this, and I’ll write up below what I have done to address the issues.
Qio-Tek Zealot H743 Flight Controller
I saw on the ArduPilot discord that this flight controller was recently (maybe at version 4.1.6 or 4.1.7) added to ArduPilot and when I took a look at the Qio-Tek.com website, I was blown away by the specs, especially for the price. So I ordered one and I’ll be using it in the Binary. You can now buy these at SmartFleet.systems, a North American authorized reseller.
I was originally going to use the PixRacer, but got stuck when I realized that with only 6 servo outputs I would not have enough for extra controls like the camera pan/tilt if I wanted to do anything like:
differential thrust on the motors
separate channels for ailerons
flaps
retractable and steerable landing gear
So reluctantly I decided that this would not be a PixRacer build. I’m a little disappointed, I really like the PixRacer but I am going with the ZealotH7 and that’s it.
So what’s so nice about the Zealot? Here’s a few things:
Built in AT7456E OSD! (analog, but built in – works great)
2M of Flash and 1M of memory – great for LUA scripts
2x i2c connectors (in addition to the one for the Compass/GPS)
2x FD-CAN connectors
2x Barometers, 2x Gyros, built in Compass
Internal 5V, 1.5A internal BEC
14 PWM Outputs with independent power rail
Built-in BEC (6S 1.5A) power input for servos
Includes external GPS/Compass, WiFi module, 14S power module, Safety button/buzzer, i2c/CAN splitter, SD Card and bunch of cables
On top of that, it’s very cheap. About 1/2 the price of a Durandal!
Wing Loading
The Binary is notorious for “tip stalling”, probably induced by the small wings. (There are lots of videos about this on YouTube). So I have a plan. What I will do is this:
Extend the wings. Add about 6cm to each wing about where the flaps/ailerons gap is on the wing.
Widen the wings. Add about 3cm in a ‘stripe’ just behind the Motor nacelles and in front of the flaps/ailerons. So not for the full length of the wings. This wider area is just to the part where the wing extension goes. Beyond this the outer part of the wings are standard.
Add washout by twisting the outside section of the wing after adding the “stripe”
Add a second spar to in the back of the wing – about where the ‘widening’ strip goes. Not full length, probably about 1/2 the wing length.
This will reduce the wing loading and move the centre of lift towards the back of the plane. This means the plane is less likely to be tail heavy and can safely carry more weight.
Surgery
Surgery
Reconstructed
Other problems
As I built out the model I noticed something else that might have caused the problems that others have reported. Rag the Nuts off (on YouTube) said something about the motor mounts but I don’t think he looked at it closely enough. I was worried about the flimsy plywood motor mounts that came with the model and I 3D printed mounts I found on thingiverse.com, but even then I found the mounts came loose very easily. I have now screwed and glued the motor mounts into the plane, but I check them carefully each time I fly because I have found they wriggle loose.
Paint/Covering
I’m using Mod Podge “Hard Coat” to provide a shell like casing over the entire foam surface of the plane. 5x coats dries to an amazing tough shell. I guess it’s an experiment, but I’m going to try this in place of packing tape or laminate or other covering/protection.
I’m going to paint this some outrageous colours, with primer over the Mod Podge and then acrylic paint. But I can’t see investing a huge amount of time/effort in it. I’m definitely not using the stock stickers but I’m going for visibility more than anything.
I’ve found the Mod Podge is amazing. The strength and rigidity it gives to the plane are excellent and it’s very resilient to little bumps and knocks. However the Mod Lodge doesn’t seem to make a great base for painting, so I’m finding that the paint chips off, but it only affects the look, the Mod Lodge shell under the paint is solid and reliable.
Wiring
I’ve built myself an “active” wiring layout because there is a lot going on and I want to make sure everything is working before I build it into the plane. What is happening here is”
Zealot H743 running ArduPlane 4.2.3 mounted pretty much right at the CoG – mounted facing forward so there is no compensation required.
Qio-Tek Power Distribution board connecting a 4S battery to the flight controller and ESCs.
2x SonicModell 40A ESC’s. One of the power outputs from these will be diverted so as not to burn out the servo rail on the flight controller. This creates a very useful extra 5V regulated power output that should be perfect for …
Both of these ESC’s also have additional pigtail battery voltage (VBAT) connectors. One of these will likely be used for the video transmitter and camera and the other will probably drive the navigation lights.
6x 9g metal geared servos. SonicModell kit provided. I don’t know if these are digital or analog. Ailerons x2, Flaps x2, Elevator x1, Rudder x1. I’ll run separate connectors to each servo, because I want to be able to trim each individually.
Nose wheel steering and retract. 1x Retract motor + 1x Steering servo (still TBD)
FPV Pan camera mounted at the front. 1x 360 degree pan camera.
Caddx Ratel 2 FPV Camera +
Bosom TS582000 Video Transmitter (requires a PWM output for settings)
This requires at total of 12 PWM Outputs including the motors (which will be separately controlled to allow for differential thrust).
This is what it looks like.
Wiring “diagram”
Express LRS
I’ve wired up a Namimno Express LRS micro receiver to a UART on the Zealot. I’m using a UART because I seem to have no other choice for this. For some reason, there is no SPI (or other) connections available for any Express LRS receivers, except for the ones that are built into the flight controller. Very disappointing. But OTOH it “just works”. I also set up Yaapu telemetry on my Open TX radio (still haven’t made the leap to Edge TX), it’s kind of awesome to watch the artificial horizon on the HUD and get direct updates like the flight mode, displayed and announced by the transmitter.
Ardupilot parameters required to get this working are:
SERIAlx_PROTOCOL = 23 (RCin)
RC_OPTIONS = 288 (existing value bit 5 [arming check throttle] = 32 + bit 8 + 256)
bit 8 = CRSF (Crossfire) passthrough
bit 9 = Suppress Crossfire mode/rate message
bit 11 = Crossfire RSSI shows Link Quality
The ExpressLRS communications need to run in “Wide Mode” so that we get fully resolution on at least the first 12 channels. Express LRS updates each channel at 1/8th the packet rate, so to update a servo at 50hz, you need to the packet rate to run at 500Hz. This is a compromise with range. so to get longer rage the packet rate needs to be lower. I’m going with 500 Hz to start and might experiment with a lower rate later once I start to make longer flights.
The telemetry ration is how often telemetry packets are sent back to the transmitter. I higher number means slower updates on the transmitter, but a lower number increases latency since more bandwidth is consumed with teletry. I’m going to go with 1/8 to start.
It’s also important to Turn off ADC filtering in radio (System Settings, Hardware) for Express LRS.
Benwake TF-Mini-S i2c LIDAR
The lidar comes out of the box set for UART (grr) and the provided cable needs to have the tx/rx lines reversed to work. (pull the green and white pins out and flip them on one end). To set to i2c, connect to an FDDI adapter using the provided cable, make sure the lidar is working, then use the Benewake windows “Test app” to send the command:
5A 05 0A 01 6A
5A 04 11 6F
5A 05 0A 01 6A (to switch to i2c mode)
5A 04 11 6F (to save settings)
Warning! As soon as you do this, the lidar will stop working. all of sensor readings will stop and the screen will freeze. You will think you have broken it. This is because i2c and FDDI don’t talk and it’s actually fine. Connect the LIDAR to the flight controller and configure these settings:
RNGFND1_TYPE = 25 (BenewakeTFminiPlus-I2C)
RNGFND1_ADDR = 16 (Bus address of sensor for the TFminiS)
RNGFND1_MIN_CM = 10 (Rangefinder minimum distance)
RNGFND1_MAX_CM = 500 (Rangefinder maximum distance)
RNGFND1_GNDCLEAR = 9 (Distance (in cm) from the range finder to the ground)
RNGFND1_ORIENT = 25 (Rangefinder orientation: 25 = Down)
RNGFND_LANDING = 1 (Enable rangefinder for landing)
It should be working. If it doesn’t work, I have no idea how you would debug or fix it, but I’ve done this twice now with 2 different devices, so it does work.
Qio-Tek ASP5033 Digital CANbus/DroneCAN Airspeed sensor
CAN bus is so nice. There is no messing around, pretty much turn it on , plug in the device and it works – at 1Mbps! These are the parameter values:
CAN_P1_DRIVER = 1 (requires reboot before doing the rest)
CAN_P1_FDBITRATE = 1000000 (this will default - no need to change it)
ARSPD_TYPE = 8 (CANBus/DroneCAN)
ARSPD_USE = 0 (set to zero to start until flown to make sure it's working)
Video Transmitter/Camera
There will be one camera (Foxeer Razer Nano) mounted on the tail for flying FPV and a Runcam Thumb mounted in the canopy on a pan/tilt mechanism for recording. There will also be a Caddx Ratel 2 on the front of the pan/tilt. I’m not sure yet how I intend to use these, at very least they will be ‘pluggable’ so that either camera can be used for a particular flight.
The Video transmitter will be mounted inside the fuselage above the camera bay. There is a perfect cavity at the back of the plane behind camera bay where a transmitter antenna can be mounted so that it is protected. I’ll mount a circular polarized antenna in this space. This is the TS582000 VTX with antenna mounted on the shelf that will slide into the slot provided above the camera bay:
The white wire on the side is for “Smart Audio”, not really audio at all, it provides 9600 baud control Link from the flight controller to the transmitter to control output power. This is especially useful on a high powered transmitter as it can easily overheat and power should only be applied when needed and not “on the bench”. Smart Audio has a “Pit mode” and ArduPilot understands how to enable this, so by connecting the yellow wire to Rx on UART5 (and also ground), the following configuration settings give pretty complete control of the VTx Power output.
Parameters for setting the VTX control on the flight controller. First set VTX_ENABLE = 1, then reboot. A number of new VTX options will be displayed.
VTX_ENABLE = 1 (enabled)
VTX_POWER = (set to the power you want from your VTX - working?)
VTX_POWER_MAX = 1000 (set to the max power of the VTX)
Retractable Landing Gear
This plane will have a retractable nose wheel. The rear wheels will be fixed, but I want to be able to mount a camera on the underside of the aircraft, so getting the nose wheel out of the way will be essential. Not to mention – the drag, retracting the nosewheel will significantly reduce the drag. So how does it work?
First – I bought a retract set from BangGood. It has 3 sprung wheels and those can be used for spares. The main nose wheel retract and one set of wheels will be installed. The retract has a single PWM style servo cable that connects to the flight controller. It uses two settings PWM < 1200 to retract the wheels and > 1800 (or thereabouts) to deploy them for landing/takeoff. This is connected to PWM output “Aux1” = servo pin 9 on the flight controller. A steering servo is also attached to the wheel and this is connected to PWM output “Aux2” on servo pin 10.
Retracts should work both manually under pilot control (set to Switch B and RC Channel 7) on the radio transmitter and also the flight controller must to be able to retract the wheels automatically for auto takeoff and landing.
To make all this work, these are the ArduPilot parameter settings:
RC8_OPTION = 29 (Landing Gear)
SERVO9_FUNCTION = 29 (Landing Gear)
LGR_ENABLE = 1 (refresh parameters after setting, no need to reboot)
LGR_DEPLOY_ALT = 8 (deploy when less than 8 meters from the ground)
LGR_RETRACT_ALT = 12 (retract when higher than 12 meters from the ground)
should be higher than LGR_RETRACT_ALT
LGR_OPTIONS = 3 (this is the default – retract on takeoff, deploy on landing)
Ground Steering also needs parameters set and tuned to work. The basic one is (GROUNDSTEER_ALT = 5.0, STEER2SRV_TCONST = 0.5)
Ardupilot Parameter configuration
There are a lot of steps required to set up a basic plane configuration with ArduPilot, but although it seems like a lot, if it’s organized it really isn’t too bad, although it would be great if ArduPilot had a “configurator” like iNav or BetaFlight as tracking down all these parameters is a bit laborious and potentially error prone.
Hardware components
Each piece of hardware has it’s own requirements for configuration required to get it to work. I’ve mentioned most of these above. In a nutshell:
The basic rule is don’t do anything on the transmitter. Send the raw signal (e.g. sticks etc) through to ArduPilot and let ArduPilot do it’s magic. This applies to everything except for RC passthrough which is really a “passthrough” because Ardupilot does nothing with these. (so see below for special treatment for the Pan/Tilt servos).’
Outputs on my TX16S (OpenTX)
Basic Flight Parameters
For the first flight, is seems like there is a bewildering array of parameters that need to be set, but it’s actually quite simple because almost everything can be left as default. Some things might need to be added later for autonomous missions and auto takeoff and landing but this should not be done right away. Keep it simple.
Many of these are being set to very conservative values because of the known issues with the Binary. Although I think I’ve improved this (see above), this needs to be tested and proven.
MAN_ROLL_EXPO = 30% , MAN_YAW_EXPO = 25%, MAN_PITCH_EXPO = 25% – expo used when flying in manual mode
ARMING_RUDDER = 2 — Rudder right to arm, Rudder left to disarm
ARSPD_FBW_MIN 12 (10 m/s) keep the speed high until we learn more about this plane – 20% higher than stall speed
ARSPD_FBW_MAX 20 (20 m/s) assume fairly high max speed – must be 50% > MIN
LIM_PITCH_MAX = 2000
LIM_ROLL_CD = 4500 (45 degree max roll) – limit bank angle to reduce the risk of tip stall on turns.
WP_LOITER_RAD = 50 (50 meter loiter radius will be used by RTL and Loiter)
This is quite small because of my flying field. Bigger would be better but I don’t have that luxury.
ALT_HOLD_RTL = 6000 cm (60m) – this is safely above the treeline.
Advanced Flight Parameters
Automated Takeoff (TKOFF_TDRAGSPD = ??, TKOFF_DIST 75, TKOFF_THR_SLEW = 20, TKOFF_TDRAG_ELEV = 0) TKOFF_TDRAG_ELEV is set to keep the nose wheel on the ground.
Flight Options (16 = climb to ALT_HOLD_RTL before RTL)
Geo Fence Options
As you may know, I’m a big fan of the Geo Fence Options. These are the ones I’m likely to use, but to until the basic flights and auto tune have been created. Some of these options are generic (always on) and some depend on their being a fence set up on the vehicle.
So this is an opinion. There are some facts to back up my ideas, but mostly it’s about my thoughts.
As I write this in June 2022, it’s less than a year since I cracked open the box on my first real flight controller (a PixRacer R15), flashed ArduPilot and started figuring out how this magical technology works.
In many ways though, I’m not a complete novice, I’ve been working in IT for more than 35 years, I wrote my first computer programs around 40 years ago. I’ve built working computers from chips, components and solder and I’ve assembled and connected many of them over the years, but I am new to RC flying, flight controllers and autonomous flying.
So when I heard about UARTs being used to connect other components to flight controllers in 2022, I assumed this would be some kind of new, leading edge technology. Boy was I wrong!
Back in the 1980’s I used to connect serial terminals to Linux hosts (we didn’t call them servers in those days). They would be connected via point to point RS-232C cables and a fast terminal would run at 38,400 baud.
Wyse 60 serial computer terminal – 38400 baud
So it turns out that UART stands for “Universal Asynchronous Receive/Transmit” – and it’s basically the same thing as RS-232, which is a standard from the 1960s. RS-232 and RS-485 are both different kinds of UART! The only difference is that flight controller UART’s run slightly faster, a standard PixHawk UART runs at 57,600, but that’s barely faster than the old fashioned green screen serial terminals we used to used back in the LAST CENTURY!
This is unbelievably slow. The old standard flight controller UART speed for a PixHawk was 57,600. 57K baud is the speed a fast dialup modem internet connection used to be in the 1990’s.
The new standard UART speed seems to be “115,200”, about double – which is is about 115k bits per second. Yes K, not mega or even giga – its 115k bits per second!!! (or about 11 Kbytes per second).
Even the slowest USB 1.0 connection is capable of 12Mbps and modern USB3.0 can do 5Gbps – which is between 100 and 44,000 times faster than a UART if I have my math right. Other alternatives commonly used are i2c, CAN, and SPI – all massively faster than UART and – since I didn’t say it clearly yet:
A UART is a point to point protocol. Each port can connect one and only one device!!!
Even the lowly i2c can support multiple devices on a single flight controller port.
CAN is specifically a bus based protocol that is designed to daisy chain multiple devices off a single port.
SPI is also a bus style interface that supports multiple devices connecting to a single port and running at “up to” 60 Mbps although limited to “short distances”. Most Flight Controllers seem to have an SPI port but it rarely gets used. Why is that?
Most Flight Controllers have at least 1 and sometimes two USB connections able to run at “USB speeds”, which could be connected to a USB hub allowing multiple devices.
The H743 processor (and most H7 class processors) have embedded Ethernet. Why do so few boards surface this high speed interface?
I’ve just ordered a new Benewake TFmini-I (CAN) LIDAR which has a default baud rate of 250k. Still a lot faster than a UART.
So why do flight controllers use UARTs?
Even more than that – why do flight controllers have so many UARTs? It seems to be a momentum thing, but I just don’t get why the community isn’t demanding more.
The ZealotH743 has 2x i2c ports and 2x CAN ports and 1 SPI port which can all support multiple devices- but there are 5 UARTS!!! Such a lot of output port real estate is wasted on UARTS!
50% of the space used by UART ports!
I will have to use a UART to connect the Express LRS receiver I just bought – but why? There have to be better options. Some flight controllers are now being delivered with “built in” Express LRS receivers. These use on-board SPI interfaces to connect to the ELRS receiver, so this begs the question – why can’t external Express LRS boards come with SPI which is available an most flight controllers?
Surely a CAN, i2c, SPI, Ethernet or USB connector would not be too hard to wire in to a receiver?
Most flight controllers have i2c, CAN, SPI and USB connectors – all MUCH faster than UART, and all capable of connecting multiple devices to a single port. Not to mention fiber optics. Why are fiber optic interfaces at fiber optic speeds not available on flight controllers?
Not much needs a UART, Digital Airspeed sensors are available as i2c and CAN, Lidars as i2c and CAN, even ESCs can be connected via CAN, CAN based GPS modules are available, companion computers such as the Raspberry PI could use Ethernet to talk to the flight controller if it was supported by the flight controller.
So this is my big question – why, in 2022, is UART still being used for connecting peripherals to flight controllers?
