Hello guest, if you read this it means you are not registered. Click here to register in a few simple steps, you will enjoy all features of our Forum.
This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
First FPV quad build
#1
I'm using this thread to document my first FPV quad build. As background, I'm getting into quads after some exposure to collective pitch helicopters.  I'd been playing around with a Blade NanoQX, but started wondering what was next.  Something with exposure to FPV but still in the micro brushed class made the most sense, and I opted to build rather than buy. 

I'm not planning on including all the build details - just capturing highlights.

[Image: 30984b.jpg]


Thread table of contents -

COMPONENT SELECTIONS 
FRAME OVERVIEW 
SCISKY 32 v1.2 NOTES
INITIAL OBSERVATIONS
ALTERNATIVE FRAME DESIGN FOR VIBRATION ISOLATION
MY CLEANFLIGHT LEARNING CURVE
DRIFT REDUCTION INSIGHT


I'm not going to get into the DX6i configuration or Cleanflight configuration unless it's asked for.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
[-] The following 3 users Like Helibus's post:
  • Drone0fPrey, fftunes, Tom BD Bad
Reply
Login to remove this ad | Register Here
#2
COMPONENT SELECTIONS

Frame - I wanted to use a 3D printable frame design so I didn't need to worry about breaking a frame and then having to wait on a replacement, assuming it was still available.  Coming up with my own design would allow me to tweak away at the frame, rather than being stuck using someone else's fixed design. 

Flight Controller - Scisky 32 (now v1.2).  Integrated DSMX receiver. Available from USA stock (Picnic Quads) at a reasonable price, small, lightweight.  Cleanflight preinstalled and only a few tweaks reportedly needed before first flight.

Motors - Racerstar 8520 8.5x20mm 53500RPM. I already had an order in work with Bangood, and the price was more affordable than MMW.  

Props - QR Ladybird. Lots of people recommending them; I could buy a quantity at a reasonable price

Camera/VTX - Hyperion MiniCAM all-in-one, which turns out is just a FX797T in a Hyperion box.  Available from USA stock, small and light.

Batteries - Striving for flight duration here. Goal for the frame was to handle something in the neighborhood of Venom 400 mAh, NanoTech 500 mAh or NanoTech 750 mAh, depending on weight tolerance. 

VTX voltage regulator - Rather than risk killing the FC's on-board 5v converter as apparently many have, I opted to use a standalone Pololu U3V12F5.  Small and light.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
[-] The following 3 users Like Helibus's post:
  • Drone0fPrey, Tom BD Bad, Oscar
Reply
#3
FRAME OVERVIEW

Initially, I seriously considered just getting a Dream Catcher from MMW or any of several small frames from Picnic Quads.  But as the intro mentions, I opted to try going with a 3D printed one so I could print my own replacements.  There's all sorts of micro quads on Thingiverse, but none jumped out as a clear-cut winner for what I wanted to do, and none that I saw included source files that I could use (preferrably openSCAD).

The openSCAD design I came up with follows the arc style of the Dream Catcher and the punkkills 105mm FPV frame on Thingiverse, but beyond that I tried to approach the design from a fresh perspective.  

Rather than print a flat base for the arcs as if they were cut from CF, I went with an arc with a flat base and an upright ridge that seems like a reasonable compromise between strength and minimal weight.  I ended up with the VTX, FC and vreg all on one plate.  I initially thought about isolating that plate from the arc frame with dental bands, but the initial design looked quite heavy. I figured I'd revert to that later if there was a need to. The plate design centers the FC MPU-6500 sensor at the xy center of the frame.  The need to do this may be arguable, but I looked at it this way - no one ever argues that you're better off with the FC sensor NOT in the center. The VTX is positioned in front of the FC at what would accomodate a maximum tilt angle on the VTX, even though a particular print may actually use less of an angle. This way, the overall characteristics of the frame aren't affected by changing the camera angle.  The rear side of the plate is sized to match the front.   This keeps the plate symmetrical and there's plenty of room behind the FC for the voltage regulator.  

After toying with various add-on plates for the battery, the initial design just adds simple risers to the lower plate that the battery sits on, with hooks for rubber bands built into the bottom of the risers.  The risers are positioned independently from everything else so that they can be shifted to adjust the overall CoG.  Other than just strapping the battery to the bottom of the frame (which would probably also work), this seemed like the lightest thing I could do.  

The motor mounts are reinforced where they mesh with the frame, hoping to reduce failures reported on other designs.  The motor mounts can be printed with a lip at the bottom that the motors sit on. I opted to print the first frame without the lip so that I can experiment with moving the prop plane up and down with respect to the rest of the quad.  The motors ended up spaced 80mm apart front to rear, and 76mm side to side for a diagonal size of about 110mm.

The openSCAD design is customizable through various top level options and dozens of parameters.  Parameters for the components (motors, props, etc.) are used to show the components in their installed locations. (The image here has the prop view disabled)

[Image: openscad%20view.png]

I printed the frame in PLA.  It's what I have the most of, and it's what I have the most experience with.  IMO, PLA also provides a more rigid print at room temperatures than at least the few rolls of ABS that I have.  It was pure coincidence, but the Voltivo Excelfil Signal Orange PLA is an exact match for the Walkera QR Ladybird orange blades.  The final prototype frame printed at 11.8 grams.  Earlier frames were printing in the 10g range, but the final versions added the optional arc in front to help protect the VTX, and added a few mm to the plate height so that a notch for a mating USB cable could be added to the plate rear wall without much loss in strength. 

[Image: 30951b.jpg]

There isn't much surface area at the top of the risers for the battery to sit on.  I have no problem adding supports in slicing, but I know many do. Anticipating I'd publish the frame on Thingiverse, the risers have an angled strut underneath to keep them printable without supports.  To increase the size of the riser top, the riser height would have to increase, leading to more weight and causing interference with the VTX antenna lobes, so the VTX would have rise up, etc. etc. 

To help keep the battery from sliding around, I dabbed the flat top of each riser with a few coats of liquid electrical tape, which has worked well as a no-slip surface.

[Image: 30969b.jpg]

I'll emphasize that this is a one-piece frame. There's no assembly hardware that adds weight.  And the open-channel nature of the lower plate allows everything else to be added/removed from the frame as a subassembly. Nothing needs to be unsoldered and resoldered to move the components to a new frame.

The intent is for the VTX to be glued to the angled side wall ridges provided for it.  I somewhat like this since it gives the VTX a "break away" strain relief rather than being hard mounted.

Clearance under the FC board is used as a wiring channel for the VTX power.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
[-] The following 4 users Like Helibus's post:
  • Drone0fPrey, fftunes, Tom BD Bad, sloscotty
Reply
#4
SCISKY 32 v1.2

Personally, I would have preferred to see the v1.2 distributed as some new product, not as a revision. IMO it isn't functionally equivalent to the original board. Being new to the scisky, I found it confusing and frustrating that there's now conflicting information out there on how to use it/configure it.  The v1.2 has also migrated to an MPU-6500 sensor, which I've read many people dislike over the MPU-6050 like on the original board.  

For the unaware, the v1.2 board appears to really be oriented to an integrated  VTX or VTX/OSD configuration, like this one on overskyrc.  The two JST-SH connectors that were II2C and UART on the original board have been replaced by two rows of pads and a single JST-SH connector.  The rows of pads are for connecting to the VTX daughter card, and the JST-SH connector is for the camera audio/video connection.  There's also a bank of LEDs on the FC that are mostly used to display the VTX band & channel.  

[Image: 30954b.jpg]

I've seen questions from many people asking about the rows of pads.  The pinouts are defined at overskyrc for the VTX configuration.  +5V from the on-board source is available on the rows of pads or on the audio/video connector.  

The board I received has no Quanum logo, FWTW.  The board works, but the assembly quality is poor.  The components appear to have been positioned by hand before soldering.  One cap wasn't even laying flat on the board, what yet soldered  on both ends.  Thankfully I had the where-with-all to reflow it. 

[Image: 29757a.jpg]

Finally, I was quite annoyed by the pads with miniscule holes for the battery leads.  I realize the holes are likely just vias to connect pads on both sides, but why not make the holes large enough to accept something like #22 or #24 wires?  You probably can't feed larger than #26 wire into the pads.  I thought about drilling them larger, but opted to just tack-solder the battery leads onto the top of the board.

EDIT: To expand on likely confusion between board versions, another option now available is to get a Scisky board with an STM32 F3 processor instead of the F1 used on the original board and the v1.2 boards.  Based on images online, the F3 boards are marked as v2.1 and are based on the F3 EVO design, not Naze.  So they'll require a different firmware load, right?
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
[-] The following 1 user Likes Helibus's post:
  • Tom BD Bad
Reply
#5
INITIAL OBSERVATIONS

AUW for the completed quad is in the 55-56g range.

[Image: 30982b.jpg]

The initial frame leverages a "hardmount" option in the openSCAD design for the Scisky mounting. This adds small risers under six clear areas along the board edges. The FC sits on the risers and a few dabs of glue hold the board flush with the top of the plate on the frame.  I saw this as a trade-off. Sure, it risks getting vibrations onto the Scisky, but the bottom of the board is kept open for airflow (has lack of airflow been a reason why the 5V source dies for people?).  Also, the components on the bottom side of the Scisky are not all the same height.  Mounting it with double sided tape or even sitting it on foam might leave the board installed off kilter, something I'd rather not do.  And finally,  seeing the solder quality of my board, there's *no way* I'd ever try to use double sided tape on it unless I felt the installation would be permanent.  Should I see problems with vibration, one path forward would be to print a soft edge wrap for the Scisky and then enlarge the lower plate as required to accommodate it. 

The printed frame is surprisingly rigid.  Considerable strength is achieved by the small struts that join the arcs to the side of the lower plate.  Also, I took advantage of the upright arc ridge and drilled a few very small holes to use with dental floss to keep motor wires flush to the frame.  

Between the two NanoTechs, the 500 mAh fits the best.  The 750 mAh fits, but keeping the battery wiring clear of the rear props can be a concern.  I don't have a Venom 400 mAh to try.  The liquid tape on the battery risers is working out well.  I'm now experimenting with that used as a coating in the motor mounts.  Unless the liquid tape forms some sort of permanent bond with the motors due to heat, that's going to be great trick for holding motors in similarly printed frames. 

This is a small frame. It's a bit of a pain to get the battery strapped in, especially under the lobes of the VTX antenna. There's not a lot of clearance between the rear props and the battery or battery wires, depending on how the motors are vertically positioned in the motor mounts. It's not so bad with the motors installed all the way upwards.  

With the 500 mAh NanoTech's, I'm good for 4:30 flight duration and ending up with batteries at about 3.75V.  I haven't had the opportunity to open it up much, so for now the Racerstar motors may be overkill. 

The VTX is mounted for weight distribution, but isn't being actively used.  I don't even always power it up.  

I've been battling three things -

1. My DX6i is exhibiting pot issues again, and I never know if I can trust what it's sending for pitch/roll. Thankfully cleanflight won't let me arm if the roll & pitch aren't centered - this saved me what would have otherwise been a bad flight just today.

2. Tendency to drift/roll. I knew from using my pitch gauge that my launch/land area is flat, but the quad tended to roll consistently no matter how often I calibrated the gyro. It took a while to realize that the vinyl caps I had temporarily installed on the motors initially protruding from the frame bottom were not all the same height.  I happened to have installed two taller ones on the left, and two shorter ones on the right...  With those out of the picture, now some flights are perfect, and some still have some drift, usually roll.  I may be trying to isolate the FC from the frame sooner than I thought, at least to rule that out. 


[Image: 30989a.png]

3.  Twice now cleanflight has reverted to a configuration very different from what I set up.  I don't know if the EEPROM is getting zeroed or what. What I do know is that the configuration changes the receiver setup in a way that lets the Scisky think it has bound to my DSMX when it really hasn't. So, the TX doesn't have any control. Big whoop. The problem is that the configuration cranks the motors up as soon as the board boots.  Who would have thought that QR blades could cut skin.  Dave Woods at Picnic Quads gave me some suggestions - right now the leading suspect is the USB cable used with the cleanfight configurator. 

NOTE: My initial  intention was to publish the frame design with openSCAD source to Thingiverse at some point. With the battery installation hassles, I'm now waffling on whether I will. In the mean time, anyone interested in trying the frame is free to send me a PM request for it.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
Reply
#6
(16-Feb-2017, 11:46 PM)Helibus Wrote: [Image: openscad%20view.png]

That's a really cool design!
Don't be a LOS'er, be an FPV'er :)  My Gear - Facebook - Instagram - Twitter
Reply
#7
Really nice build!

I've been pretty amazed with the durability of tack soldering for these purposes.... and my batteries fly across the field half the time I crash Smile
Reply
#8
(19-Feb-2017, 11:24 PM)Oscar Wrote: That's a really cool design!

(20-Feb-2017, 12:37 AM)CesiumSalami Wrote: Really nice build!

Thanks for the feedback.  I find it amazing how simple a brushed micro is. 

The DX6i pots seem to holding up after another teardown for cleaning.  The cleanflight config corruption was apparently related to the USB cable I had been using.

I thought the frame had a lot of promise. I've ended up hitting it into walls and fences and stuff a number of times, with no damage to the frame.  Knocked the AIO loose enough times I looped a rubber band around it to hold in place instead of gluing it.  One of the antenna lobes is already broken at the top, and yeah, the battery has popped off a few times. 

I could probably overcome or get used to the hassle of the battery bands.  I've pretty much confirmed, however, that vibes getting into the MPU-6500 are a real problem. Holds great in cleanflight rate mode, but the roll (and some pitch) in angle mode is bad. Trimming the accelerometer on the FC helps, but the setting varies - probably with motor speed.  As more confirmation, stretching the dabs of glue holding the FC to the hardmount so the FC is somewhat softmounted also makes a difference in the drift. 

Unfortunately, I'm not ready to give up angle & horizon modes and don't really want to play games with filtering options cleanflight offers.  I don't have any flex filament to use for a softmount, so I'm retrofitting the design with a tray for the FC to sit in, and the tray will then be isolated from the frame with foam tape.  Trying to get the weight back down is having a pretty hefty ripple effect through the entire frame.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
[-] The following 1 user Likes Helibus's post:
  • Tom BD Bad
Reply
#9
ALTERNATIVE FRAME DESIGN FOR VIBRATION ISOLATION

Well, I've migrated to the new frame design that mounts the Scisky in a tray that can in turn be isolated from frame vibrations with foam tape.  As mentioned before, I didn't want to apply any kind of adhesive tape directly to the many components on the bottom of the scisky board.  Since the scisky is such a low mass (2.5g), I've questioned the value in attempting to isolate the FC from vibrations but I've found it to be a recurring recommendation in resolving angle mode drift. 

Accommodating the sidewalls of the tray and clearance around the tray required adjustments to the base plate of the frame.  Wanting to maintain a frame design that others could print without supports, the wider stance of the lower plate meant the fixed risers would have to be taller to provide the same battery coverage, with weight ramifications.  The new design migrates to a more typical battery shelf on standoff posts, but I've kept the weight of that shelf to a minimum and kept the standoffs as short as possible. Lengthening the plate would push the AIO forward, exposing it even more.  To keep the tray length the same, the MPU-6500 sensor on the scisky was allowed to move rearward a few millimeters from the XY center of the frame.  Finally, reductions were made in several areas that actually shave a few grams off the frame weight.  The battery shelf is shown in the picture prepped with liquid electrical tape applied as a no-slip surface.

[Image: 30990a.jpg]


This frame has a bit more flex to it. I can selectively strengthen it as the need to do so comes up.  I figure I'm a long ways from flying aggressively enough that a bit of flex is going to be a problem.

The weight savings are lost to weight of the tape on the FC tray, nylon screws for the battery shelf, cable ties on the PLA motor mounts to help keep them in shape on hot motors (an idea from Oscar's Whoopee build), and self-adhesive felt pads used for protection under the motor mounts.  The prior experiment with liquid electrical tape inside the motor mounts worked out well, so I coated all four corners on this frame.  With FPV gear, the new quad weighs the same as the original build - 55.8g or so AUW with the 500 mAh battery.  Troubleshooting will be done without the FPV stuff installed, and this gives a very low profile result.

[Image: 30994a.jpg]


I noticed a reduction in drift, but the vibration isolation wasn't a miracle cure.  I tried two foam tapes that I had on hand. One was gray 3M automotive tape that I'd successfully used  with the flybarless unit on my Blade 300x heli, and some random thicker, softer foam tape of origin unknown. 

Since migrating to the new frame, some major headway appears to have been made in resolving the drift.  I'll post a summary of the research and experiments after I've collected some more run-time.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
[-] The following 2 users Like Helibus's post:
  • fftunes, sloscotty
Reply
#10
I know most would feel resolving angle mode drift on this build is inconsequential. True enthusiasts aren't supposed to fly angle mode.  I get it.  And compared to other builds on intoFPV and elsewhere on a scale of 1 to 10, this thing comes in at, well, pretty much a 1 no matter how you look at it.  I get that, too.  

If nothing else, working to reduce the drift continues the learning experience this build was intended for.  I'm having a blast with the quad and basic circuits in my small, tree-filled yard.  When the quad becomes my limiting factor (and not my flying skills), I'll apply the experience gained to something more capable.

The rest of this post documents more of the learning experience.  Maybe some other beginner will benefit from it.  Readers that have been around for a while may find it entertaining or even laughable.  Even I'm amused at how naive I was not too long ago. The fix to the drift is not discussed here - that should be in the next post.  Some of the info here leads into that.  

MY CLEANFLIGHT LEARNING CURVE

The exposure to Cleanflight and the CF Configurator has been fascinating.  On my 130x heli, the 3-in-1 board only had a few gain parameters that could be changed via the TX sticks and counting the number of flashes on LEDs.  The AR7200BX FBL unit on my 300x provided access to more parameters, but you still managed them through stick movements and LED patterns. How comparatively archaic.  That said, it's been somewhat challenging to get my arms around Cleanflight, perhaps since my engineering background expects me to understand what I'm doing. I've also been amazed at how people explaining something about CF apparently assume the reader is already familiar with it, since key details are often left out.  Sure, good documentation is out there for CF, but it's hard to read through and absorb dozens of lengthy files when you're looking for basic info.  My bad.  

As FYI, my Scisky came configured with CF 1.12.0 dated Jan 11, 2016, or not even a full stable release.  The latest CF build showing up in the configurator as available for the NAZE is 1.14.2.  For the record, Overskyrc states the scisky 32 board design was tested with v1.8.1 and v1.9.0. Maybe some of my learning experience is specific to the 1.12.0 CF version, IDK.  

Possibly the "best" reference I found for configuring Cleanflight on the Scisky was the following thread at Micro Motor Warehouse.  The thread content itself is helpful, as are the links to other resources people have posted.  MMW may well have lots of other great info, but I get eyestrain from websites with a black background, so I tend to minimize time spent with them.  This thread was worth it. See How to set up Scisky FC step by step.  

With time, I learned the importance of understanding the role TX sticks play in CF, beyond the expected throttle, yaw, pitch and roll.  I can't believe it took me a while to realize I had to arm the quad via the sticks.   I've learned how random stick movements can do unexpected things - like switching to a different CF parameter profile that wasn't configured.  Until the stick functions are 2nd nature, I've printed a copy of the stick function table and taped it to my battery case.  And BTW, I'm still learning how important it is to force or at least wait for disarming before bringing the throttle stick up to calibrate the accelerometer.  Otherwise throwing that throttle stick upwards can lead to things getting exciting. Really quick.  

Working through the drift issue, I grew to appreciate the accelerometer trim functions available via the TX sticks.  And I eventually learned how those trim values are reset to 0 when you command an accelerometer calibration.  Who would have thought...

I've learned how important it is to save changes in the CF configurator before leaving a page.  I've learned some changes need to be saved incrementally.  Something higher level like a mode change should be saved first, before attempting to change parameters associated with it. 

It didn't take long to appreciate the Command Line Interface (CLI), since only some features can be accessed through the GUI.  "help" is a valid command. I learned how not everything is accessed the same way.  Individual parameters are accessed through set/get functions. More complex things don't use set/get - they each have their own command.  Set commands must include an equal sign.  When you don't, you get an error regarding the parameter name, not a missing equal sign.  Be sure to use the save command before leaving the CLI. 

The CLI has a dump function that shows you everything in the CF configuration. Copy and paste that into a text file for archiving.  I grew to understand how the dump result is really meant to help you copy and paste commands back into the CLI, more so than for you as a viewer to read.  I now understand that's why parameter values are prefaced with "set" in the dump results.  

Being one that likes to study, understand and cross-check, I grew to realize it can be hard to correlate GUI settings to entries in the CLI dump.  Names can differ.  A few parameters include decimal points in both places, but many don't.  What shows up as an integer in one may be divided by 10, 100, or even 1000 in the other, with the decimal point added.  Hardly anything includes units, so I learned I can't use that as a way to better explain what the settings really mean or help me understand what I'm doing.

The motors on my quad don't form a perfect square.  They're only a few mm off from square, but I figured I'd configure CF for it since it was a minor tweak that I could understand.  I learned how all those that describe doing this with the betaflight cmix command don't realize that doing it in CF is more than "just use the CF mmix command instead".  The CF mmix command starts motor numbering at 0, and CF ignores any mmix commands that aren't in the proper numerical sequence.  I was initially quite puzzled at how my mmix commands to motors 1 to 4 never resulted in anything that showed up in the CLI dump. 

As always, I was assured how Google is my friend.  It's pretty good at pointing out pertinent documentation and references that explain things.

EDIT: Perhaps most importantly, I learned to grow wishful of a FC that would give access to blackbox type data or access to accelerometer data during bench motor testing. The scisky has no provision for on-board storage of such data. If there's an easy way to add external recording, I don't have the hardware to do it. For bench testing, connecting the battery and USB at the same time will (supposedly) damage the scisky, and of course you can't run the motors off USB power. At least not on my board. These lessons learned will certainly factor into selecting my next FC.

 -----

That's what comes to mind. I'll edit in other learning experiences as I recall them. 

Hopefully no one misinterprets the tone of the post - I'm not blasting CF or any of the developers. I respect what the developers have done and provided to the community.  These are just some pretty basic points that might help other noobs get a jump on things.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
[-] The following 1 user Likes Helibus's post:
  • jimbo_wa
Reply
#11
DRIFT REDUCTION INSIGHT

tl;dr UPDATE: The angle mode drift issue appears to be completely gone after later upgrading to Cleanflight 1.14.2 and configuring it just for the functional basics.

----------

So, the drift has definitely been reduced.  It hasn't been eliminated, but it's to the point where I can live with it.  More importantly, I think I better understand what has been going on and can continue to refine things as desired. 

To recap the issue:  Substantial drift to the right when trying to use CF angle mode.  The quad would initially hover just fine, but then want to drift more and more to the right.  I'd have to apply considerable stick to counter it (IDK, 1/3 stick?).  In rate mode, the quad was as stable as I would expect it to be with the roll/pitch stick centered.  Switching from rate mode to angle mode was essentially impossible since the quad would instantly zoom off to the right - often faster than I could deal with.  From what I've read, this isn't all that unusual of a problem.  Summarizing the possibilities I've read about or thought about -

TX isn't exactly 1500 at center stick:  Well, my DX6i *does* only provide resolution of about 4 counts on subtrim, so yeah, I can't get exactly 1500 at center stick.  But again, center stick on rate mode doesn't drift. I would also think that part of startup or calibration would be to sense what is being received for center stick, but maybe I'm wrong on that.  

Calibrate the gyro/acc:  When that  helps, the drift quickly returns.

Quad isn't level during start-up or calibration:  I try to always do this consistently on a hard surface that I've checked with a level.  

Trim the acc:   That somewhat works, but the issue is the amount of trim needed varies.  It's not constant.  I also found it somewhat annoying that the subtrim values are reset as part of calibrating the acc. 

Quad isn't balanced or motors aren't aligned right:  But the quad stays pretty stable at center stick in rate mode. 

The (plastic) frame is flexing:  Well, maybe.  But this is with just enough throttle to hover, and without any other stick action.  What could be causing it to flex?  Regardless, I have a CF frame on the way to experiment with if it comes to that. 

The FC needs to be isolated from the frame: Done that, short of trying to mount the FC on a cottonball or something.  At this point wiring to the FC is likely a limiting factor.  

MPU-6500 sensor installation concerns:  The datasheet for the MPU-6050 defines ground plane, trace routing, and board soldering expectations.  That detail isn't in the MPU-6500 data sheet, but maybe there are concerns in the Scisky layout or how the part is soldered to the board.  Nothing I can do about this one.

My MPU-6500 sensor is bad or is b-grade: Replacing the MPU-6500 worked for one person, but I'm not ready to try that yet.  

MPU-6500 is just overall a bad sensor, compared to the MPU-6050: That seems to be the conclusion many have.  Where I've seen people do a detailed technical comparison, the MPU-6500 is actually declared the *better* part, usually because it supports SPI and you can achieve more data updates that way.  As a footnote, I noticed that the MPU-6000, MPU-6050, and MPU-6500 are all designated by InvenSense as not recommended for new designs. There are newer parts to be used now.

The MPU-6500 should be used with an F4 processor, not a lowly F1 or F3 processor: I've read a few people say this, but I'm not ready to buy the argument yet.  The premise is that the MPU-6500 samples at a fixed 8 kHz rate, and only an F4 processor can keep up with that much data.  Lesser processors will skip samples, leading to undersampling concerns.  As best I can extract from the datasheets, the MPU-6050 and MPU-6500 are identical here, and both have programmable sample rates for the gyro and acc. Wouldn't CF be controlling this?  

There's something wrong in CF:  One person was emphatic on how his drift problems were caused by CF v1.12, and that he could predictably revert to v1.9 and not have an issue.  Well, overskyrc does state that the scisky was tested on v1.8 and 1.9, not newer versions.  I'm new to all this, but it also sounds like CF 1.14.0 was released with little regard to whether angle mode worked, so maybe that trend did start as early as 1.12.  Or, maybe things are actually better now in 1.14.2.  I've been holding off on trying that.

------------

WARNING: The following describes actions that others report as causing damage to the Scisky boards.  Replicate at your own risk.

My epiphany occured when I relented and connected the battery and USB to the Scisky simultaneously so I could monitor sensor data in CF with the motors running. There's a recurring mantra everywhere that you should never ever do this with the Scisky.  Some had mentioned no problem when inadvertently doing so in the MMW setup thread, so I thought I'd give it a shot.  I also figured that if I fried the Scisky, well, good riddance.  Killing the board would give me the excuse to move on to something else.

I did try to keep the period of simultaneous battery and USB connection short.  Some quick testing revealed one motor was showing off-the-scale perturbations in the accelerometer data.  The graph was clipping at +/- 2g, so who knows what CF thought the values really were.  Nothing about this motor sounded, felt, or looked any different from the others.  This only occurred with the prop on the motor.  Swapping out the prop made no difference.  Rather than keep testing and risk Scisky damage, I swapped the motor out and took the time to check and balance all of my Ladybird props.  Some props were certainly out of balance.  

An initial test flight with a new motor and balanced props looked promising.  I reran a short test to check the sensor data in CF with motors running again, and that motor position was a lot better.  Maybe still not as good as the other three, but far better than it was.  Through the couple of dozen flights since then, drift is now minor or something that a mid-flight recalibration can take care of. I can switch between angle and rate mode at will and manage to keep the quad under control.  

I can't speak to the mantra about not connecting USB and battery simultaneously.  I'm not familiar with the circuit design of the Scisky, so I can't come up with my own opinion.  Maybe the v1.2 board has changed things so there's no problem with doing so. I did discuss this with overskyrc after the fact, and they told me there should be no problem with it.  Unfortunately, I don't know if I can trust that since they also told me I should be able to run the motors off USB power, which I can't. 

Where to from here: I don't believe the off-the-scale vibration data being reported by CF could have been real.  I think it is more likely an artifact of undersampling due to either the CF parameters I'm running or in CF code itself - resulting in an artifact driven by perhaps a unique frequency of the noise from that motor & prop combination.  Should the drift problem return, I at least feel more comfortable with connecting the battery and USB simultaneously for more testing.  Yes, there are various filtering parameters in CF that can be adjusted. I briefly tried experimenting with just gyro_sync, which has been OFF in the parameters as I received them. Unfortunately, enabling that leads to an LED pattern that suggests an acc init error, so I've shelved that for now.  It may be time to jump to a newer version of CF and at least be experimenting with something more current. 

I'm open to hear corrections or other suggestions.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
Reply
#12
(23-Feb-2017, 11:52 PM)Helibus Wrote: I learned the importance of understanding the role TX sticks play in CF, beyond the expected throttle, yaw, pitch and roll.  I can't believe it took me a while to realize I had to arm the quad via the sticks.   I've learned how random stick movements can do unexpected things - like switching to a different CF profile that wasn't configured.  Until the stick functions are 2nd nature, I've printed a copy of the stick function table and taped it to my battery case.  And BTW, I'm still learning how important it is to force or at least wait for disarming before bringing the throttle stick up to calibrate the accelerometer.  Otherwise throwing that throttle stick upwards can lead to things getting exciting. Really quick.

I recommend you use the "arm" flight mode to disable stick arming / enable switch arming, like you're used to from helis. Easy enough to do, and acro tricks will become much safer as you will stay in control of the quad no matter the throttle position. You could also enable airmode at the same time, or as an extra mode, for even better "zero-throttle" performance.

Awesome build and great thread! Yet i thought i had enough quads, but this makes me want such a small one too... Big Grin
Reply
#13
It looks like my drift issue was likely due to Cleanflight.  I was seeing quite a drift again last night after posting the prior summary.  In frustration, I jumped to flashing the Scisky with CF 1.14.2, the latest stable release for the Naze 32/Scisky.  Initial testing shows no angle mode drift at all.


(26-Feb-2017, 01:53 PM)fftunes Wrote: I recommend you use the "arm" flight mode to disable stick arming / enable switch arming, like you're used to from helis. Easy enough to do, and acro tricks will become much safer as you will stay in control of the quad no matter the throttle position. You could also enable airmode at the same time, or as an extra mode, for even better "zero-throttle" performance.

Awesome build and great thread! Yet i thought i had enough quads, but this makes me want such a small one too... Big Grin

Thanks for the build comments.  Yeah, the arming discussion is consistent with what we talked about in my welcome thread.  Unless I move to a new TX, I'm limited to two usable switches on the DX6i.  To keep those available, I actually started off with the TX applying some minimal throttle and using Throttle Cut for arming, but having to then also use Throttle Cut to perform many stick functions where zero throttle is required seemed cumbersome.  Now that I'm more comfortable with adjusting CF, I can go back and rethink all this at some point.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
Reply
#14
The quad is certainly more enjoyable to fly with CF 1.14.2 installed and no angle mode drift.  Even rate mode seems easier with the default PID controller and settings. Thankfully I hadn't spent time tweaking THAT in the 1.12.0 firmware.  

For completeness, here is the current dump. Most settings are the 1.14.2 defaults -

Code:
# version
# Cleanflight/NAZE 1.14.2 Dec 31 2016 / 02:12:34 (747971f)
# dump master

# mixer
mixer CUSTOM
mmix reset
mmix 0 1.000 -0.950 1.000 -1.000
mmix 1 1.000 -0.950 -1.000 1.000
mmix 2 1.000 0.950 1.000 1.000
mmix 3 1.000 0.950 -1.000 -1.000
smix reset


# feature
feature -RX_PPM
feature -VBAT
feature -INFLIGHT_ACC_CAL
feature -RX_SERIAL
feature -MOTOR_STOP
feature -SERVO_TILT
feature -SOFTSERIAL
feature -GPS
feature -FAILSAFE
feature -SONAR
feature -TELEMETRY
feature -AMPERAGE_METER
feature -3D
feature -RX_PARALLEL_PWM
feature -RX_MSP
feature -RSSI_ADC
feature -LED_STRIP
feature -DISPLAY
feature -ONESHOT125
feature -BLACKBOX
feature -CHANNEL_FORWARDING
feature -TRANSPONDER
feature -OSD
feature RX_PPM
feature VBAT
feature MOTOR_STOP
feature FAILSAFE


# map
map AETR1234


# serial
serial 0 1 115200 57600 0 115200
serial 1 0 115200 57600 0 115200


# led
led 0 15,15:ES:AI:0
led 1 15,8:E:FW:0
led 2 15,7:E:FW:0
led 3 15,0:NE:AI:0
led 4 8,0:N:F:0
led 5 7,0:N:F:0
led 6 0,0:NW:AI:0
led 7 0,7:W:FW:0
led 8 0,8:W:FW:0
led 9 0,15:SW:AI:0
led 10 7,15:S:FW:0
led 11 8,15:S:FW:0
led 12 7,7:U:FW:0
led 13 8,7:U:FW:0
led 14 7,8:D:FW:0
led 15 8,8:D:FW:0
led 16 8,9::R:3
led 17 9,10::R:3
led 18 10,11::R:3
led 19 10,12::R:3
led 20 9,13::R:3
led 21 8,14::R:3
led 22 7,14::R:3
led 23 6,13::R:3
led 24 5,12::R:3
led 25 5,11::R:3
led 26 6,10::R:3
led 27 7,9::R:3
led 28 0,0::C:0
led 29 0,0::C:0
led 30 0,0::C:0
led 31 0,0::C:0


# color
color 0 0,0,0
color 1 0,255,255
color 2 0,0,255
color 3 30,0,255
color 4 60,0,255
color 5 90,0,255
color 6 120,0,255
color 7 150,0,255
color 8 180,0,255
color 9 210,0,255
color 10 240,0,255
color 11 270,0,255
color 12 300,0,255
color 13 330,0,255
color 14 0,0,0
color 15 0,0,0


# mode_color
mode_color 0 0 1
mode_color 0 1 11
mode_color 0 2 2
mode_color 0 3 13
mode_color 0 4 10
mode_color 0 5 3
mode_color 1 0 5
mode_color 1 1 11
mode_color 1 2 3
mode_color 1 3 13
mode_color 1 4 10
mode_color 1 5 3
mode_color 2 0 10
mode_color 2 1 11
mode_color 2 2 4
mode_color 2 3 13
mode_color 2 4 10
mode_color 2 5 3
mode_color 3 0 8
mode_color 3 1 11
mode_color 3 2 4
mode_color 3 3 13
mode_color 3 4 10
mode_color 3 5 3
mode_color 4 0 7
mode_color 4 1 11
mode_color 4 2 3
mode_color 4 3 13
mode_color 4 4 10
mode_color 4 5 3
mode_color 5 0 9
mode_color 5 1 11
mode_color 5 2 2
mode_color 5 3 13
mode_color 5 4 10
mode_color 5 5 3
mode_color 6 0 6
mode_color 6 1 10
mode_color 6 2 1
mode_color 6 3 0
mode_color 6 4 0
mode_color 6 5 2
mode_color 6 6 3
mode_color 6 7 6
mode_color 6 8 0
mode_color 6 9 0
mode_color 6 10 0

set debug_mode = NONE
set emf_avoidance = OFF
set i2c_highspeed = ON
set flashchip_id = 0
set flashchip_nsect = 0
set flashchip_pps = 0
set mid_rc = 1500
set min_check = 1100
set max_check = 1900
set rssi_channel = 0
set rssi_scale = 30
set rssi_ppm_invert = OFF
set rc_smoothing = OFF
set rx_min_usec = 885
set rx_max_usec = 2115
set serialrx_provider = SPEK2048
set sbus_inversion = ON
set spektrum_sat_bind = 0
set input_filtering_mode = OFF
set min_throttle = 1000
set max_throttle = 2000
set min_command = 1000
set motor_pwm_rate = 16000
set servo_center_pulse = 1500
set servo_pwm_rate = 50
set 3d_deadband_low = 1406
set 3d_deadband_high = 1514
set 3d_neutral = 1460
set retarded_arm = OFF
set disarm_kill_switch = ON
set auto_disarm_delay = 5
set max_arm_angle = 25
set fixedwing_althold_dir = 1
set reboot_character = 82
set gps_provider = NMEA
set gps_sbas_mode = AUTO
set gps_auto_config = ON
set gps_auto_baud = OFF
set telemetry_switch = OFF
set telemetry_inversion = OFF
set telemetry_send_cells = ON
set frsky_default_lattitude =  0.000
set frsky_default_longitude =  0.000
set frsky_coordinates_format = 0
set frsky_unit = IMPERIAL
set frsky_vfas_precision = 0
set hott_alarm_sound_interval = 5
set ibus_report_cell_voltage = OFF
set battery_capacity = 0
set vbat_scale = 110
set vbat_max_cell_voltage = 43
set vbat_min_cell_voltage = 33
set vbat_warning_cell_voltage = 35
set amperage_meter_scale = 0
set amperage_meter_offset = 0
set multiwii_amperage_meter_output = OFF
set amperage_meter_source = VIRTUAL
set vbat_hysteresis = 1
set align_gyro = DEFAULT
set align_acc = DEFAULT
set align_mag = DEFAULT
set align_board_roll = 0
set align_board_pitch = 0
set align_board_yaw = 0
set small_angle = 25
set max_angle_inclination = 500
set pid_process_denom = 1
set gyro_sync = 1
set gyro_sample_hz = 1000
set gyro_lpf = OFF
set gyro_lowpass_level = NORMAL
set gyro_lowpass_hz = 90
set gyro_notch_hz = 130
set gyro_notch_cutoff_hz = 130
set moron_threshold = 32
set imu_dcm_kp = 2500
set imu_dcm_ki = 0
set pid_at_min_throttle = ON
set yaw_motor_direction = 1
set yaw_jump_prevention_limit = 200
set tri_unarmed_servo = ON
set servo_lowpass_freq =  400.000
set servo_lowpass_enable = OFF
set failsafe_delay = 10
set failsafe_off_delay = 200
set failsafe_throttle = 1000
set failsafe_kill_switch = OFF
set failsafe_throttle_low_delay = 100
set failsafe_procedure = 1
set acc_hardware = 0
set baro_hardware = 0
set mag_hardware = 0
set blackbox_rate_num = 1
set blackbox_rate_denom = 1
set blackbox_device = SERIAL
set magzero_x = 0
set magzero_y = 0
set magzero_z = 0

# rxfail
rxfail 0 a
rxfail 1 a
rxfail 2 a
rxfail 3 a
rxfail 4 h
rxfail 5 h
rxfail 6 h
rxfail 7 h
rxfail 8 h
rxfail 9 h
rxfail 10 h
rxfail 11 h
rxfail 12 h
rxfail 13 h
rxfail 14 h
rxfail 15 h
rxfail 16 h
rxfail 17 h

# dump profile

# profile
profile 0

# aux
aux 0 1 1 1075 1250
aux 1 0 0 900 900
aux 2 0 0 900 900
aux 3 0 0 900 900
aux 4 0 0 900 900
aux 5 0 0 900 900
aux 6 0 0 900 900
aux 7 0 0 900 900
aux 8 0 0 900 900
aux 9 0 0 900 900
aux 10 0 0 900 900
aux 11 0 0 900 900
aux 12 0 0 900 900
aux 13 0 0 900 900
aux 14 0 0 900 900
aux 15 0 0 900 900
aux 16 0 0 900 900
aux 17 0 0 900 900
aux 18 0 0 900 900
aux 19 0 0 900 900

# adjrange
adjrange 0 0 0 900 900 0 0
adjrange 1 0 0 900 900 0 0
adjrange 2 0 0 900 900 0 0
adjrange 3 0 0 900 900 0 0
adjrange 4 0 0 900 900 0 0
adjrange 5 0 0 900 900 0 0
adjrange 6 0 0 900 900 0 0
adjrange 7 0 0 900 900 0 0
adjrange 8 0 0 900 900 0 0
adjrange 9 0 0 900 900 0 0
adjrange 10 0 0 900 900 0 0
adjrange 11 0 0 900 900 0 0

# rxrange
rxrange 0 1093 1940
rxrange 1 1085 1925
rxrange 2 1085 1945
rxrange 3 1065 1960

# servo
servo 0 1000 2000 1500 100 -1
servo 1 1000 2000 1500 100 -1
servo 2 1000 2000 1500 100 -1
servo 3 1000 2000 1500 100 -1
servo 4 1000 2000 1500 100 -1
servo 5 1000 2000 1500 100 -1
servo 6 1000 2000 1500 100 -1
servo 7 1000 2000 1500 100 -1

set gps_pos_p = 15
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 34
set gps_posr_i = 14
set gps_posr_d = 53
set gps_nav_p = 25
set gps_nav_i = 33
set gps_nav_d = 83
set gps_wp_radius = 200
set nav_controls_heading = ON
set nav_speed_min = 100
set nav_speed_max = 300
set nav_slew_rate = 30
set alt_hold_deadband = 40
set alt_hold_fast_change = ON
set deadband = 2
set yaw_deadband = 2
set yaw_control_direction = 1
set 3d_deadband_throttle = 50
set throttle_correction_value = 0
set throttle_correction_angle = 800
set default_rate_profile = 0
set gimbal_mode = NORMAL
set acc_cut_hz = 15
set accxy_deadband = 40
set accz_deadband = 40
set accz_lpf_cutoff =  5.000
set acc_unarmedcal = ON
set acc_trim_pitch = 0
set acc_trim_roll = 0
set baro_tab_size = 21
set baro_noise_lpf =  0.600
set baro_cf_vel =  0.985
set baro_cf_alt =  0.965
set mag_declination = 0
set pid_controller = LUX
set p_pitch = 40
set i_pitch = 30
set d_pitch = 23
set p_roll = 40
set i_roll = 30
set d_roll = 23
set p_yaw = 85
set i_yaw = 45
set d_yaw = 0
set p_alt = 50
set i_alt = 0
set d_alt = 0
set p_level = 20
set i_level = 10
set d_level = 75
set p_vel = 120
set i_vel = 45
set d_vel = 1
set pid_delta_method = MEASUREMENT
set yaw_p_limit = 500
set yaw_lpf_hz = 0
set dterm_lowpass_level = HIGH
set dterm_lowpass_hz = 100
set horizon_tilt_effect = 75
set horizon_tilt_mode = SAFE
set gtune_loP_rll = 10
set gtune_loP_ptch = 10
set gtune_loP_yw = 10
set gtune_hiP_rll = 100
set gtune_hiP_ptch = 100
set gtune_hiP_yw = 100
set gtune_pwr = 0
set gtune_settle_time = 450
set gtune_average_cycles = 16

# dump rates

# rateprofile
rateprofile 0

set rc_rate = 70
set rc_expo = 65
set rc_yaw_expo = 0
set thr_mid = 50
set thr_expo = 0
set roll_rate = 0
set pitch_rate = 0
set yaw_rate = 60
set tpa_rate = 0
set tpa_breakpoint = 1500

#

A few minor adjustments have been made to the frame.  I snapped off a motor quadrant in a high drop to a hardwood floor, so I've added back some of the strength previously removed from the curved arcs.  I also added two more frame options in the openSCAD script - rubber band hooks for optional use with break-away mounting the AIO and mounts for an optional rollbar.  I used Grainger item #2XPT9 1/8-inch polycarbonate rod; the picnicquads rollbar would also work.  For added robustness, the rollbar rests against the front of the battery plate.  The latest build-up weighs in at 57.7g AUW with a NanoTech 500mAh battery.  I also remembered I had some Panduit PLT.6SM-M30 subminature zip ties in my older RC stash, so the latest build uses those on the motor mounts instead of the more typical 4-inch/100mm variety. I've even reinstalled the original motor that was problematic with the 1.12.0 firmware, and see no issues with it.

[Image: 40006a.jpg]
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
Reply
#15
The frame has been released to Thingiverse, including the openSCAD script source.  See http://www.thingiverse.com/thing:2157726.
Kevin B.
Quads:
Custom 110mm FPV, NanoQX w/DX6i
Other: 3D printing (printer buildThingiverse), electronics, AVR microcontrollers
[-] The following 1 user Likes Helibus's post:
  • fftunes
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Build Armattan Tadpole 3" 2-3S Build brettbrandon 40 2,321 Yesterday, 11:56 AM
Last Post: SnowLeopardFPV
  Build GEPRC SMART Walksnail 2.5 Inch Toothpick build Cyberess 28 765 26-Mar-2024, 10:21 AM
Last Post: hugnosed_bat
  Build Low profile 3 inch prototype quad design ph2t 24 692 11-Mar-2024, 03:53 PM
Last Post: skywanderer
  Help 3 inch toothpick build is EXTREMELY sensitive! swequad 20 642 01-Mar-2024, 04:03 PM
Last Post: swequad
  Advice for sub 250 3" 03 Air build B4tn 5 159 14-Feb-2024, 02:48 PM
Last Post: skywanderer


Login to remove this ad | Register Here