Martian III Quad build – Part 3

In the previous part of the build, we’d installed all the electronics into the frame, and had pretty much completed the physical build – I’d stopped at the top plate and it’s four risers just so they weren’t in the way for heat shrinking the ESCs.  We’ll come to that part in a little while, first up, we need to look at the Flight controller configuration through Betaflight and check if we need to alter any of the ESC setting through BlHeli suite.

So let’s turn our attention to the flight controller.  I attached a USB cable between the flight controller and my computer and connected it up to Betaflight.  Checking the version it was running, I found it was running the slightly older 3.0.0 version of the firmware.  So the first thing I did was flash the latest 3.1.7 version onto the board.  If you are new to Betaflight and the concept of flashing flight controllers, be sure to check out my video about it here. If you are really new and are wondering what Betaflight is, then check out my intro video to it here.

The firmware on a decent level, I connected up Betaflight and went through the setup.  The first thing I did was set UART3 to serial, so I could use my XM+ receiver on SBUS.

Next up, in the configuration tab, there were a few changes to make.  I set my ESC/Motor protocol to DSHOT600, and selected the MOTOR_STOP option.  Lots of people seem to like their motors immediately spinning up when arming, but where I often need to take off and land in long grass, I want the props to stop quickly – without me having to think about disarming as well.  I still use Air mode of course, but that’s on a switch that I turn off when I come in for a landing.

Obviously, to complete the receiver setup on UART3, I selected SBUS.  The boards Gyro and Pid rate had defaulted to 8kHz/2kHz, so I decided to leave it at that.  You can probably run the PID loop faster on this board, but I’m not convinced you get that much more after you go past 2kHz.

I disabled all the features I wasn’t running.  Whilst the flight controller has an SD card slot so I could store lots of Black box logs, it’s not something I’m particularly interested in – unless I’m trying to track down a difficult issue.  So I disabled everything except for the OSD.  On the subject of the OSD, I named my craft as “CurryK” as this lets me place my name in the OSD display.  This isn’t so much about vanity, as to alert people who are on the wrong channel that it’s not theirs…. unless by some chance they also have the word “CurryK” on their OSD intentionally !

Failsafe is left as default, so onto PID tuning – where there wasn’t much to do.  It seems that in the majority of cases now, the default PIDs fly really well – with the only thing I ever want to change is the Super Rate curve.  This has a default value of 0.70 on Roll/Pitch/Yaw, so I leave that as profile 1, and set profile 2 up as 0.77 – which is what I fly on some other quads, finally putting the rate up to 0.80 on profile 3, which I use on a few other quads.  The difference in that 0.03 is bigger than you might think.

Into the receiver tab, and I checked the sub trim and end-points of my 4 main channels.  As I’d copied this model over from another on my Taranis, there was barely anything to do here.  But one additional important task was to set the RSSI channel as 8 – as I’d flashed the specific version of the XM+ firmware to support this.

As far as my modes go, I’ve settled on an absolute standard set for all my quads, and use the same switches for every model on my radio.  I’m almost trapped with this now, as any change would completely throw me.  For months after going from stick arming to switch arming, I’d still be going through the disarm stick movements after I landed.  Muscle memory is a powerful thing.

I have a logical switch on my radio which means that air mode won’t activate unless the quad is already armed – it may look confusing from looking at it from Betaflights point of view, as it doesn’t know that the air mode switch won’t do anything until the arm switch is on.  I just about fly 100% of the time in acro, but I’ve always kept a self-level mode available as a “just in case” idea… I haven’t needed it yet though.  Finally, the beeper mode – which is well used for finding my quad in a crash.

Nothing needed on the adjustments or servo tab, so on to the motors next – which means plugging in a lipo !  Actually, I’d already plugged one in earlier to check for magic smoke, but before hand I checked my wiring, and then I checked it again, and then once more for good luck.  Occasionally, something will slip past me, so I don’t think I’ll ever quite be free of the tense moment of plugging in for the first time.  But if I had any advice, it would be quite literally: check and check again – because you will find things and wonder how on earth you plugged/soldered things in the wrong way around.  Of course, before plugging in, make sure the VTX has some type of antenna screwed into it else it’ll burn itself out.

So in this initial stage, I wanted to check is the motors were spinning in the correct rotations.  It should go without saying, that I had no props on to do this, so please please don’t ever put props on.  This isn’t even about – you can keep the props on if you know what you are doing – it’s a case of never ever have the props on.  I’ve had motors seemingly go crazy and spin up fully for no apparent reason.  With the props on, this would have caused a serious injury and destroyed half my house.  For the space of a minute with a spanner, it’s not worth leaving them on ….. ever.

Ok, lecture out of the way, I went through each motor in turn, checking the way it span.  Sometimes it’s not obvious – and I use a piece of tape to help me see the direction it’s turning.  Predictable – as all the motors were soldered on in the same way – they all ran in the same direction.  Motors 2 and 3 were good, and 1 and 4 needed to be reversed.

Yay for BLheli suite, which lets us alter the motor direction through the flight controllers interface – although until recently, as a Mac owner, this was still a pain as I had to use a virtual Windows 10 machine in order to run it.  But with the advent of a Chrome app (making it cross-platform) of BLheli, this is a very quick and easy job.  If you don’t already have it, then download it here. Using the app, I reversed the direction of motors 1 and 4 (although looking at the screenshot I took – that’s the ‘before’ picture), and then jumped back into Betaflight to finish off.

Normally, my next action would be to calibrate the ESCs using the motors tab, but the combination of BLheli_S and DSHOT meant there is no calibration to do.  This threw me for a while, but I tested the motors through Betaflight, and they all started up perfectly in sync.  So I moved on to the OSD tab.  Wiring up a MicroMinim OSD used to be a massive pain – although the MWOSD firmware was very good – but having experienced having an OSD on the flight controller itself, I don’t know if I’d ever have the stomach to go back to installing my own.  But why oh why, is the default OSD display so bad.  Take a look –

I find it quite hideous, there’s no point to the artificial horizon in a quad, and it never keeps up, and why is the timer information floating half way up the screen.  Madness !  Before I went to work in rearranging things, I used the bold version of the font.  It’s much clearer to read and stands out against well against the video.

I like to keep only the relevant information on my OSD and spread it out as much as I can to keep most of my view clear.  I have my lipo voltage bottom left, mode bottom centre, flight time bottom right, RSSI top right and my call sign top left.

I thought that was going to be everything in Betaflight, but I hadn’t flown a race-style quad before with a lipo mounted underneath and what I noticed from this is that the chance of it being perfectly level was unlikely.  Even on a very level floor, the quad leant over a bit.  So in an uneven field of lumpy grass, this could be more acute.

I didn’t want to get into a situation the quad was at too much of an angle to arm.  The is affected by the small_angle attribute, which by default is set to 25 (so any more than 25 degree tilt and it won’t arm).  I set this to 180 – which lets me arm the quad no matter what angle it’s at.

With the Betaflight and Blheli setup done, I could finish off the last few parts of the build.  There wasn’t much to it.  I first heated the heat shrink over the ESCs.  So I didn’t heat anything else, I removed each motor in turn so I could hold the ESC away from the frame and direct my hot air gun accurately.

After a few experimental tries about how to route the FrSky antennas, I settled on putting some cable ties around some slits near the rear of the top plate.  I then put heat shrink over the top of these, threaded the antennas through the heat shrink and shrunk it in place.

To finish off the build, aside from screwing the top plate and it’s risers in, I also secured the ESCs in place with wrapstrap and put the stickers on them (mainly because if I didn’t, I’d forget what they were inside a week).  I’ve used a skew planar antenna from AKK Tech a few weeks ago – the Rush VTX I’ve installed uses an SMA connector.

If you are wondering what’s going on with the props – where are the tri blades ?  I got out some DAL 5x4x3’s only to find I had a single CW prop and 7 CCW props… so that wasn’t going to work.  I had lots of 5×4.5×3 props, but these would pull too many amps.  Having a look at the data for the motors, I could maybe just about get away with the tri blades, but I went with the DAL 5045BN’s for the reasons of a) it seemed safer, and b) I didn’t have any suitable tri blades.  That said, the data mentions 5045’s, it doesn’t mention 5045BN’s, so I could still be pushing it too much.

I charged up a 4S 1300 and took the quad into the garden for a quick “sanity-check” hover.  Everything felt good, and certainly looked very smooth – although there seems to be a tiny throttle distance between ascend and descend so perhaps a throttle curve is in order.  Finding a pure hover point seemed difficult – but so is flying and overpowered little quad in the constraints of my tiny garden.

I’ll go out for a proper fly in the next few days, where I’ll be back with a proper review of how the components hang together, and what I liked/don’t like about it all – and, if applicable, that changes I made.

One thought to “Martian III Quad build – Part 3”

Leave a Reply

Your email address will not be published. Required fields are marked *