105 g 3" 1S Nano 4.3 DEV

I have a 3" 1S Li-ion quadcopter that is based on arducopter using the JHEMCU GSF405A 1S-2S AIO F4 FLIGHT CONTROL W/ 5A ESC & ELRS 2.4G RX. I have ran the initial setup and saved those parameters. When I go to start my first hover the quad is wild and completely unstable. I have confirmed the props spin the correct direction and all props are in the correct direction. Upon the first unstable initial flight I followed these instructions reducing the parameters in those instructions by 50% each time but have almost reduced them down to 0 and have not been able to get anything to come off the ground.

short bin file
nano.param (17.6 KB)

First off - this looks like a really fun build. I’ve been wanting to get my hands on one of those FCs myself. As for your issue - I don’t have a ton of experience with this kind of thing, especially for something so far outside the “normal” Arducopter build size. But in looking at your log, I noticed that there is some clipping in the accelerometers that increases over the time of the flight, just like it mentions here as a warning sign of an issue. Measuring Vibration — Copter documentation Could it be that the mounting for your FC needs to be improved somehow?

It is a very fun build, I have a cpl on betaflight flying and they are really fun inside and not bad outside. Yes its flight is very wild and hit the ground a few times which is where those are coming from I believe. Right now it is completely uncontrollable and will clip a prop and flip over. I will try and find some other hands to record video and maybe get a longer log but considering its pretty much uncontrollable I’m not sure it would help.

I can’t see anything obviously wrong in your setup - I suspect MOT_SPIN_MIN and MOT_SPIN_ARM might be too high.

I did an initial tune video, maybe it helps IDK - ArduCopter 7" LR Build Video 16 - Initial Tune and Notch Configuration - YouTube

I have lowered the MOT_SPIN_MIN to 0.03 and the MOT_SPIN_ARM to 0.01. I also have updated the blheli_s esc with the latest stable version of bluejay (0.16) and am getting rpm data. I completely reset the flight controller to defaults by uploading plane than copter back on and ran the initial setup for a 3", 1S li-ion and saved the results. I also watched your video which helped greatly for a more comparable build the same size but given this is completely different (half the prop size and way way smaller battery) it didn’t seem like it would cross reference very well. This is the most unstable quad on arducopter I have ever built. Do you think I need to attach some foam to the baro as its just sitting there in the open face down?

I have attached a video of the wild ride when trying to take off. I also have no halved the parameters like I did above.
cf_nano_refresh.param (17.8 KB)


My first venture into AC was with a similar, very small quad, and the results were also similar. :wink: I ended up porting the components to a bigger frame (4.5" and 3S) with much more success. At the time I drew the conclusion that AC is just not made for nano quads. But that was 2 years ago, so I’m not saying it cannot be done today. And yes, I would guess some vibration dampening would definitely help.

My positive experience with AC and small and extremely light quads starts before 2017, we make Ardupilot drones for light shows using Skybrush outdoor and indoor. If you search “Ardubee” here on the forum you will see our first one under 100g with 3" propellers. Already it flew very well, we made a second version mini-LuminousBee – LuminousBees and now we are in production with the newest version 3 (weight 94g) and in a few weeks it will be ready. In a nutshell it flies great and Ardupilot has no limitations in this type of small craft. The times I had problems tuning it was when the imu was malfunctioning, so my advice is don’t give up and if all the components are working properly I don’t think you will have problems to find out the right tuning and make it flying excellently :slight_smile:

I have built, tuned & flown a whoop weighing 24g dry and 40g wet, using ArduCopter and this particular board.

I must admit though that this wasn’t an easy journey. My first build was heavier (as it contained a different camera capable of recording 4K video) and I never got it flying well - because either the weight distribution was not healthy, or the motors were not up to the task, or the vibration level was too high. So I had to get rid of that camera and use a tiny carbon frame.

Here are few things that seem to be worth considering.

  1. Edit: there was nonsense.

  2. The board seems to be really sensitive to vibrations, so you may want to add some more dampening to it. Your level does not seem to be high though.

  3. You don’t seem to cover the barometer with some foam. This is needed, otherwise you will not be able to use any of the auto modes, including AltHold, due to insanely erratic height estimation.

1 Like

When I conduct a motor test they all spin in the proper order and direction. I will take some foam and rubber dampeners tonight when I go in. Are you using ELRS on the little fella?

Yes, I use ELRS, and that has been pretty much fun so far. I must admit, however, that the antenna placement seems way suboptimal in my case, so I will probably replace that antenna with one from a HappyModel receiver and put it somewhere under a motor similar to how 915MHz antennas are placed.

I apologise for my analysis in the previous message, your servo functions are correct.

The default PIDs don’t seem to be good anyway, especially the roll ones. You would definitely want to divide them by two (before engaging AutoTune, which shows what’s possible for your craft).

What is more interesting, you will most likely benefit from increasing maximum accelerations (ATC_ACCEL_P_MAX, ATC_ACCEL_R_MAX). I think you want to make them 1.5x as large. Small copters are too fast, and they may change their attitude way faster than Ardu’s suggested defaults think is possible. My small build has the following values:


which might be too much for yours, but your build shall easily tolerate values of 300k for pitch and even more for roll.

1 Like

If you are on ELRS v2.x.x are you using rudder arming or ch5 high. thank you very very much for the help with start tuning I hope to just be able to take off in stabilized to start then play with tune a bit and hopefully engage autotune from althold!!!

I have reconfigured all my vehicles to using Channel 5 for arming.

The technically safest way is to use rudder arming and to assign Channel 5 to Motor Interlock. However, some acro moves are dangerously close to the rudder gestures, so this is why I got rid of them.

P.S.: tuning vehicles across the Internet is a pain actually. The last case which drove me crazy was related to harmonic notches configured according to the latest instructions, which happened to be incorrect at the time of reading. This resulted in a harmonic notch that was filtering out EVERYTHING. Luckily we got through it (and the instructions have been fixed since then).

I had read that thread about it being in the control and rc zones. I wonder if me not having ch5 high for arming may be causing some issues as well as default params being way off for such a light vehicle. tonight I will disable rudder arming and enable arming on ch5 and change some params as you advise hope to see it off the ground tonight.
I to am now working through harmonic notch filters on a 5 and two 6 inch builds i think I am finally getting somewhere with it!!

Not having CH5 high is quite likely to cause various synchronization issues on the RC level, resulting in failsafes even when the vehicle is not very far. The entire logic of ELRS is highly bound to the condition of CH5 being high when you are in the air.

As for PIDs and other control parameters, that stuff is always highly vehicle-dependent. The physical meaning (and dimensions) of the PID quotients is quite non-trivial, so they are not independent on the sizes. On the other side, angle rate limits have known dimensions, so the scaling laws are kinda known - but these laws assume the same mass distribution, and the same thrust-to-weight coefficients, as in some “reference” vehicles, which are, apparently, in the 10" range. Smaller quads are way out of that reference sequence, and in generally unpredictable directions, so it is harder to find a “basically flyable” region of parameters.

Seriously? I’m not a developer by any means, but that really sounds odd…

Also I can confirm AC is ‘made for 10"’ - my largest copter flew surprisingly well on defaults.

First of all, channels 1-5 are the only channels that are guaranteed to be sent in each packet. This way, something like an arming switch or a motor killer needs to be assigned to that “fast” channel, otherwise timely motor shutdown is not guaranteed.

Second, the receiver has no FC-independent means of understanding whether the vehicle is armed other than CH5. This knowledge is used in at least one feature, NO_SYNC_ON_ARM, which turns off synchronization packets when arming. This is, of course, not an option which an average ArduPilot user would use. However, since CH5-is-high is a known synonym for being in the air, the safest thing is to maintain that invariant in all setups.

Thanks for the information. Looks like I should stick with Crossfire - for my taste, there are already enough things to pay attention to when configuring and building.

So last night I went down the rabbit hole and found no working parameters that worked with this quad. I added a foam cover to the baro and soft mounted the FC with rubber dampeners to help with vibes. As @MaxBuzz mentioned I increased the ATC_ACCEL_P_MAX , ATC_ACCEL_R_MAX to 1.5 times og values and even almost 2.5 times. I have been reading here and adjusted settings based on what i thought would work with a 3" prop but no combination of anything works. I also adjusted my ELRS arming to make sure ch5 was high to eliminate any of that wonkiness from the setup and recalibrated my radio and all the mandatory steps. One thing I will say is even with mot_spin_arm to 0 when I arm they still spin up and my mot_spin_arm is 0.01. I have about 5 of these board so maybe its the board but sure doesn’t seem like it.

A wild guess - may the latter be the BlueJay configuration issue? They have their own equivalent of minimum input that causes rotation; maybe it is just set, say, below 1000?