FliteTest Electrohub Tricopter build from a novice/noob's point of view.

makattack

Winter is coming
Moderator
Mentor
I just completed building a tricopter around the electrohub kit, purchased at FliteFest 2014, and the RTFQuads flight electronics. I added some 3528 sized LED strips purchased from eBay to the bottoms of the boom for orientation / low light help.

It was mostly a straight-forward build, but I did run into a few things that might be helpful to have documented for someone else new to all this.

A lot of the information at http://witespyquad.gostorego.com/videos.html was helpful to get started, but I also think that watching youtube videos can be a little time consuming if you're trying for figure out a specific problem.

I built the tricopter using the original FT Tilt motor mount, because the "Tuff Mount" isn't available yet. I know that I could also have done a 3D printed version of David Windestals new motor mount for his V3 Tricopter, but the kit I purchased came with the old tilt, so I went with that. I had also purchased the camera/battery tray / plate -- but ultimately didn't mount it (more on this later).

The frame build was very easy, based on the FliteTest electrohub build video, but noticed that the 7/64 drill bit I initially used was just a little too small, and given I wasn't using a drill press, needed a little more play in the holes to line up the screws for both the top and bottom plates. I re-drilled the holes with a 1/8" bit, and everything was great.

I followed the advice of Alex, Josh, and Peter in the build video and soldered the motor wires directly to the ESC's. I did have some 550 cord (parachute cord which can be bought online, at Army/Navy stores, or even fabric stores) which I cut to length, pulled out the inner strands, heat sealed the ends, and surrounded the motor wires with the 550 cord sheath to keep things tidy.

The soldering was somewhat uneventful except for the desoldering of the existing motor leads on the ESC's. The wires that came with the RTFQuads ESC's are fairly large gauge 16AWG wires -- in contrast, the wires on the motors are 20AWG. It took a lot of heat from my soldering iron to get those wires off the ESCs. HINT: use a bit of fresh solder on the tip to ease the desoldering by making the heat transfer better. I noticed Peter doing that in the build video, after I had already figured that out.

I next had to decide how I was going to setup the motors. I decided to make them all counter-clock-wise (CCW) due to the fact that I had plenty of 9x4.7 CCW/conventional props and I know as a new pilot, I'll be breaking plenty of them. Using a servo tester to check the motor direction was a great idea featured in the FT build video.

After all the soldering was done, the frame completed, I secured the motors along with the Flip 1.5 flight controller and my Frsky X8R receiver onto the frame. It was at this point I put together the tilt motor mechanism, mounted that to the boom, and installed the servo, a Turnigy 375DMG (Digital Metal Gear) servo I ordered from Hobby King. I had bought two in case I broke one in a flight, but it turned out one was DOA, so I was able to use the other one which worked great.

With the servo and motor wires connected as per the multiwii docs and the rtfquads wiki, I went onto binding my Taranis X9D+ with the X8R receiver. The binding was successful, and done with the props off for safety, but I noticed that the yaw servo was moving with the throttle and realized the Flip1.5 was flashed with a quad configuration. Well, at this point, I set about installing and configuring the computer to work with MultiWii. Thankfully, I already have been using my laptop for other arduino based projects, so most of the drivers and the arduino IDE itself was already installed and working. I installed MultiWiiConfig, and downloaded the RTFQuads customized version of the tricopter multiwii 2.3 package from the RTFQuads dropbox download area. After selecting the "Arduino Pro / Pro Mini" board type, I installed the tricopter sketch without changing anything, and connected the MultiWiiConfig to the Flip1.5, and saw that everything was working normally. Even the yaw servo setting was correct based on how I had installed the servo.

At this point, I went and watched a video linked to from the RTFQuads wiki page titled "Flip 1.5 / Multiwii for dummies" to get a crash course on the multiwii config tool and see what else I needed to know. I also saw that there was a tricopter specific video I could have seen to before I started all this. Ultimately, the tricopter video would have been helpful to get me to the last step more quickly -- to realize I would have had to reprogram the flip for tricopter use. The dummies video was useful for learning about the flight modes, RC calibration and how one can power up the Flip 1.5 via USB *and* the servo rail via a battery. This is a no-no on APM, so it was interesting to see MultiWii/Flip apparently has this voltage limiting / isolation feature.

At this point, I decided I wanted to implement the ARM/DISARM function on my TX using the X9D "SF" two position switch, and the flight modes using the X9D SE three position switch. I plug additional signal wires to the AUX1 and AUX2 input ports on the Flip 1.5, and the other ends to the next available channels on the X8R RX. At this point, I thought about using SBUS or PPM, but I don't have the necessary parts for that (SBUS -> PPM converter or SBUS inverter cable -- nor do I know how that would work on a flip1.5). I'll attach a printout of my Taranis configuration for those who might be interested.

Next, I balanced the props I had, and mounted them for some prop-on bench testing. I know, it's a little dangerous, but I wanted to check to see that the yaw, pitch, roll inputs were correct. Turns out, they were. I didn't need to reverse anything on the TX nor the Flip1.5. I basically connected a battery to the tricopter, then, while holding it down, armed it, and put the throttle up just enough to spin the motors with a steady RPM. I carefully picked up the tricopter, and in angle mode, checked to see that it would try to compensate with opposite force.

OK... need to return to this at a later date... Happy Thanksgiving to those in NA!
 

joshuabardwell

Senior Member
Mentor
If you need to test motor direction, two approaches (taught to me by FT) are to put a "flag" of tape on the shaft, or to set the props on the shafts, but don't tighten them down. They will spin slowly from the friction, but won't have any force.
 

makattack

Winter is coming
Moderator
Mentor
Here are the only two pictures I took, as I suspect I'm fairly late to the game and there are many better build pics and videos out there:

Nearly complete:
tricopter_build.jpg

Completed build, bench tested:
tricopter_buildcomplete.jpg

I was a little nervous leaving it powered up, even disarmed, to take a photo, so I took the props off.

The next part, which was to test and do a more detailed configuration of the software based on the bench testing took quite a bit of time. This was based on my early experience with Arduplane/Ardupilot on my Versa Wing. As you see from my above post, I still couldn't resist plugging in a battery even before I knew what was flashed on the flight controller.

So, to sort of summarize what I had to do for the software configuration:

* Set the tilt/yaw servo limits in the multiwii config
* Change the multiwii config to handle a higher servo refresh rate appropriate for a digital servo
* Change the TX programming to use extended ranges (130% at both ends for throttle, yaw, pitch, roll)
* Program in the flight modes and arm switch
* Adjust the yaw PID to dampen some twitchiness I observed while bench testing.

I still have to do the following:

* Set the failsafe -- this will actually require a maiden to figure out the throttle setting needed for a self landing.
* Tune the Roll, Pitch, Yaw PIDS and set the rates and expos.
* Learn to fly a multi-rotor larger than a nanoqx!
* RMA the dead TGY375DMG servo
* Figure out what to do with the FT battery/camera tray

The FT battery/camera tray doesn't quite fit the tricopter configuration if you build the tray to specifications set out by FliteTest. Turns out the rear plate attached to the curved music wire falls right underneath the bolts securing the rear boom. I could cut the ply under the bolts to fit the plate flush to against the bottom frame plate, but felt like that was a project for a later date, or maybe even a different airframe. Why not try making an electrohub deadcat/spider quad for that and keep the tri a bit more sleek? That decision is dependent on how I like flying the tricopter, budget, and time. In the meantime, I just put velcro/hook and loop tape on the bottom of the frame, and a hook and loop strap through the two large wire holes at the front of the plates to secure my battery. I can always stick my mobius actioncam to the front of the top plate and any VTX off the side/rear.

Here are the changes I made to config.h:

Code:
     // The physical servo limits when used with the following equipment works well:
     //    FliteTest tilt 13-370 motor mount
     //    Turnigy 375DMG servo
     //    Frsky X8R receiver
     //    Frsky X9D+ transmitter
     #define SERVO_MIN  {1200, 1200, 1200, 1200, 1200, 1200, 1200, 1200}
     #define  SERVO_MAX {1700, 1700, 1700, 1700, 1700, 1700, 1700, 1700}
     #define  SERVO_MID {1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500} // (*)

    /* up to 300Hz refreshrate it is as fast as possible (100-300Hz depending on the cound of used servos and the servos state).
       for use with digital servos
       dont use it with analog servos! thay may get damage. (some will work but be careful) */
    #define SERVO_RFR_300HZ  // I commented out/disabled the default 50Hz refresh rate for this since I'm using a digital servo.

Here's my Open-TX for the X9D+/X8R setup:

View attachment x9d_x8r_config.pdf

NOTE:

Based on this post from joshuabardwell, I realized my end-points were way too big on the Taranis.

I've since re-adjusted them to fit the 1000-2000pwm range which ended up requiring slightly less than 100% rates on both ends. Now, my throttle kicks the motors on as soon as I move the stick up.
 
Last edited:

makattack

Winter is coming
Moderator
Mentor
If you need to test motor direction, two approaches (taught to me by FT) are to put a "flag" of tape on the shaft, or to set the props on the shafts, but don't tighten them down. They will spin slowly from the friction, but won't have any force.

Ah, yes, I definitely did that -- using the tape, while testing with the servo tester right after soldering the motors to the ESCs. I also used the loose props resting on the motor bell/shafts as a final check to make sure they were roughly working correctly for the bench test, but found that I couldn't test the multiwii configuration well enough. I wanted to make sure when I moved the tricopter on the roll, pitch, yaw axis, it input opposite force. Mounting the props tightly was also useful for testing the relative stability. I could feel it lighten up in my hands, and exert even force. Of course, it is a dangerous way to test -- if I lost grip, it would have been disastrous. So, don't do this! Do NOT do this! Nope...

With APM, and a fixed wing airplane, I can observe and see the control surfaces doing the right thing. On a tricopter, other than the yaw mechanism, I couldn't visually see what it would do rolling and pitching.

I did notice that there's a dynamic balance mode in multiwii -- which won't allow it to fly, but this older video shows how it would work -- basically, you use your TX to select each motor individually, with all props attached and the aircraft connected to your computer. You then hold down the frame while running each motor up to about 50% throttle and add weight to the prop or bell as needed. Assuming the props are balanced, I would hope it's only the bell that needs the weight. I'm intrigued enough to try it before my maiden flight:
https://www.youtube.com/watch?v=k_aIcOvJJSQ

I guess that's still risky, but shows the value in this sort of testing. Nevertheless, as DavidW would say... nope... don't do it!
 
Last edited:

joshuabardwell

Senior Member
Mentor
I tried the dynamic balance mode, but for whatever reason, it didn't reliably spin the motors up and down. Frankly, dynamic balancing is so hit-or-miss, I can't really seem to get the knack of it. It's hard to tell whether an accelerometer trace has gotten better or worse, especially since you have vibration in three axes. I wish there was something that would convert the accelerometer data into an absolute magnitude that went up or down as you improved the balance.
 
Last edited:

makattack

Winter is coming
Moderator
Mentor
I'll probably try they dynamic balance mode tomorrow with the following method:

1) Test each motor without the prop / spinner
2) Test each motor with the spinner only
3) Test each motor with prop and spinner

Yeah, the graphical trace may not offer much more than a rough "average" -- I'm actually more curious about it more than anything else. I've balanced the props and motors as discrete units, but want to see what happens when they're all put together.
 

makattack

Winter is coming
Moderator
Mentor
Well, I enabled the dynamic balance mode on the version of MultiWii 2.3 I downloaded from RTFQuads, and it exhibited the same behavior that Joshua experienced.

From the MultiWiiConfig tool, in the "Motors" tab, I could select a motor, and set the PWM level via mouse, but it didn't work with the TX. Oddly enough, it sort of had a mind of its own and would randomly run up the left motor. Very odd. Definitely glad I had the props off for testing it. I should just leave it be and pick a day to charge up some packs for a flight test. It seems I've done all the bench work I can given what I have and my resources.

Oh, one more thing I did setup: failsafe. It's odd though, I tried to setup the X8R and the Taranis/X9D+ to both use the "no ppm signals" on failsafe -- but it just wouldn't "take" -- it kept using the "hold" or last channels state failsafe. Obviously that's pretty risky for a fly-away situation, so I found I had to override the failsafe behavior with a custom setting:

-100 throttle and 0 on my aux1/channel 5 setting (putting it in angle mode). I also have aux2/channel 6 set to 100 to keep it in armed state. This way, I figure if I get a momentary loss in signal, it will level, drop, and stay armed in case it gets back in range. Of course, I may set the throttle higher to have a softer landing... but not sure yet.
 
Last edited:

joshuabardwell

Senior Member
Mentor
Yeah. That's exactly what happened to me. BTW, if you do stuff like that with the props on, make sure the quad is thoroughly restrained. I had a five pound box of welding rods sitting on top of a long piece of flat steel that was passed through the battery tray. I was doing the ESC calibration and accidentally rebooted the FC without resetting the ESC's at the same time. All motors came on full throttle and the thing tried to fly away. Because of the leverage on the piece of steel, it was able to lift up one end of the box of welding rods. Luckily, it ended up just flipping over onto its back (motors still screaming) and I was able to pull the plug.
 

makattack

Winter is coming
Moderator
Mentor
Yikes! Yeah, I get super nervous with flight controllers and how they basically have "minds"of their own.

Speaking of flight controllers... if people are using identical esc's with integrated lbec's, what are the issues with using only one power lead on the servo wires going into the flight controller vs leaving all the red/middle power leads in? Is there a sync risk? Seems the redundant power could be useful. I've not seen a definitive answer.

The esc's in using are these (3):
http://witespyquad.gostorego.com/sp...rmal-esc-with-rapidesc-fw-for-multirotor.html
 
Last edited:

cranialrectosis

Faster than a speeding face plant!
Mentor
Yikes! Yeah, I get super nervous with flight controllers and how they basically have "minds"of their own.

Speaking of flight controllers... if people are using identical esc's with integrated lbec's, what are the issues with using only one power lead on the servo wires going into the flight controller vs leaving all the red/middle power leads in? Is there a sync risk? Seems the redundant power could be useful. I've not seen a definitive answer.

The esc's in using are these (3):
http://witespyquad.gostorego.com/sp...rmal-esc-with-rapidesc-fw-for-multirotor.html

I started out building with all three wires from the ESCs connecting to the flight controllers. Now I simply use the signal wire and power the flight controller with a ubec, pololu or ESC 1. I find it makes for a MUCH cleaner copter and have seen no adverse effects. I also only solder the pins I need to a Naze32 so doing this means I only solder 6 pins to a Naze32 for a quad. Much much cleaner. :)
 

makattack

Winter is coming
Moderator
Mentor
In thinking about it more, and seeing cranialrectosis' response, in addition to craftyDan, Andre, and Gary's response via other channels, it all depends on the fc. The kk board has a split servo power rail setup, and may require a second power feed if servos are being used. With the multiwii/flip1.5, that isn't the case as there is only one power rail on the servo side. Generally, it's safest to only have one power source so that there isn't a chance for fluctuating voltages to feedback to the other becs that might be connected in parallel.
 

makattack

Winter is coming
Moderator
Mentor
Ok... silly question, to those of you who've got much more experience with these things... I'm sure, but I have a single pack charged and am ready to take it outside for a quick little hover test / maiden / training flight.

I suspect I'll just try to hover it over one spot for the whole pack, maybe try a few landings and takeoffs -- but therein lies my dilemma.

What's the best way to take off and land? As I see it, I have one of two main options for takeoffs.

1) Slowly throttle up until it's light on the skids, then add throttle more quickly to take off.

2) Pop it up to the air as fast as possible with a smooth motion to 1/2 throttle, which is sort of how I take off on my nanoqx. I've just never flown a multirotor of the size of the electrohub, so not sure if it's any different. I'm thinking it is more like #1.

Follow-up question: Do I take off in acro mode and stay there? Do I take off in acro mode and switch to angle mode? Or just take off in angle mode?

Landings: To avoid the ground effect and descending turbulence, should I land with a little forward momentum or just land as vertically as possible over one spot?

It's supposed to warm up to the low 50's deg F tomorrow where I am, so it sounds like a good day for a flight.
 

joshuabardwell

Senior Member
Mentor
Once you get experienced, you will want to authoritatively take to the air, getting out of ground effect as fast as possible. If you have experience flying your Nano, you should do okay.

If you intend to fly in Angle/Horizon mode, there's no reason not to take off there. I prefer to fly in Acro/Rate mode, and I think you will be a better pilot if you do that too. Not to mention that you don't have to bother with ACC calibration! But when I was beginning to learn to fly, flipping from Acro to Horizon mode saved my bacon more than once when the copter was getting away from me.

I recommend landing as vertically as possible. Reduce the throttle until you start to descend slowly. As you enter ground effect, the copter will become unstable. Neutralize as much velocity as you can and then cut the throttle in a smooth motion. Don't just chop it and drop the copter onto its skids, but don't do it so slowly that you spend a lot of time in ground effect and pick up horizontal velocity.
 

cranialrectosis

Faster than a speeding face plant!
Mentor
When I am testing a new build or re-launching after a major crash, I slowly lift the copter off the ground and always in acro mode (all self levelling algorithyms turned off). I also record this so I may review it later.

I am listening for whines (berings) rattles (loose stuff), pings (obstructions in the motor bells) and watching for rotor slippage and for instaflip (I didn't connect something right).

Once the copter is in the air, I move it front to rear, side to side and spin it. I am looking for tuning issues such as over corrections and wobbles from too high PIDs or sloppy movements caused by too low PIDs or poorly assembled frame. I will hover in place and punch the throttle. I am looking to see if the copter tips toward any motors when I give it power. This might indicate an ESC or motor or rotor problem on that motor.

Then within 1-2 minutes, I set the copter down, test all the motors and ESCs and lipo for excessive heat, pull the lipo and go back to the bench and test-tighten EVERY single nut.

This is a maiden and I always do them in calm air.


For anything else, I pop the copter into the air with authority to get it out of the wash and into the clean air.

If you have the space to fly, learn in acro mode. Don't even look at anything else until you can fly in acro mode well enough to tune PID. If you fly in an enclosed space, you may have to learn in autolevel (horizon or angle or autolevel depending on the board) mode. If you do, simply practice hover, spins and figure 8s until you can control your copter in your enclosure. Once you can 'fly' in autolevel mode in your enclosure, practice hovering in acro mode until you can tune PID. The alternative here is to tune indoors with the copter tied down.

FT has a nice tutorial on how to learn to hover in the beginners section on the show. The key to learning to hover is throttle control. This will take weeks to learn. The key to learning to fly is keeping orientation. This you will practice for the rest of your career as a pilot. Put lights on the copter to show you the front and rear or use bright colored props. Don't learn to fly the back end of the copter. Put the bright rotors on the front.
 

makattack

Winter is coming
Moderator
Mentor
Thanks for the great advice Joshuabardwell and Cranialrectosis! Great information. I actually just got back from the first flight. It was amazingly uneventful and a great learning experience to boot.

I went to the softball field a few minutes walk from home. Usually it's used by off-leash dog walkers, against the park rules, but this morning there was only a couple with a small dog who arrived at the same time I did. I set the tricopter on a stone bench I usually use for range testing, and performed the range test on the new RX (Frsky X8R). I was very happy with the results. About 50-60 RSSI value from 30' away from all compass directions. Due to the geography, I could only test 180 degrees before I have to go back and turn the aircraft around to test the other half, so it's a little time consuming. The dog walkers were looking at me funny throughout the process. By the time I was done, they were wrapping up the morning exercise routine for their pooch, but a few more folks were arriving with much bigger dogs -- which probably scared the original couple away as well.

Due to the busy conditions at the field (now 3 medium to large dogs running around) -- I moved to an area behind the softball field keeping a chainlink fence between the dogs and my area of operation. The field I fly at normally, Davis field that's used by my club (CRRC) is also a public field popular with dog walkers who are officially allowed to be off-leash, but the folks there are used to seeing airplanes flying there. It's a much bigger space, but with an untested airframe I just put together, I needed more seclusion.

Unfortunately, the first take off attempt didn't go too well. This was the first time I had set it down on grass. In setting it down, I decided to reset the gyros once more (full left rudder/zero throttle + full up elevator/back cyclic -- ok, another question, when flying rotary wing, do people change terms for describing the channels / sticks?) -- because of the yaw servo movement, this calibration movement sent the tail into an oscillating feedback loop. Curious about that, I moved it to a concrete area and did the same calibration, but this time without the oscillation. Repeated this on sand in the softball diamond. Again, no oscillation. So, apparently, grass/turf with this particular build of mine will give me an oscillating tail boom. I have this setup with the default RTFQuads MultiwiiTricopter PIDs except for the yaw channel, where I lowered them from the original 6.8,0.045,0 to 5.8,.03,0 based on the bench testing I did coupled with a youtube video linked to from RTFQuads from a guy who had also setup a tricopter.

At any rate, I was worried about taking off from a hard surface (concrete) and a sandy surface (worried about sand getting into the motors) so I moved it back to grass to see if that would still work. Unfortunately, as I spun up the motors, the tail boom oscillated again and was even worse, so I chopped the throttle and moved it over sand for my first take off.

That take off was great. The a/c lifted off, blowing sand and leaves away, but it was momentary and I didn't hear any grinding noises. I took off in acro/rate mode as recommended by everyone here. I was super surprised that I didn't need to trim the yaw. I thought for sure I would need to adjust my rough manual tilt of the rear servo horn to give the motor a small 2-3 degree tilt to the right to give it a little left yaw, as per David Windestals (rcexplorer) FliteTest video on the scratchbuilt tricopter. The a/c was hovering practically hands off in one spot with no yaw drift.

I was also amazed and confused about the ability of this flight controller to allow for such a steady hover in acro/rate mode, so I'm assuming there is some self leveling that has to be happening here. I know with my nanoqx, I have to give far more constant adjustment to keep it in a steady hovor in full acro mode. I need to do more research into multiwii flight modes was what went through my mind.

With this confusing bit going on, I decided to land, after about a minute of hovering. This time, I decided to move it back to the grass as the sand blown up just made me nervous. Back on the grass, I double checked to make sure I was in full rate/acro mode. Indeed, I was according to the switch setting on the TX. Still unsure of it, I picked up the a/c, throttled up a bit until I felt enough force, then tilted it forward to see if it would correct the pitch. Nope... ok... acro mode, right?

I set it back down on the grass, and took off. This time, I ignored the boom oscillation, and was able to lift it off the grass which quieted down the boom immediately. Good. Everyones advice about "hopping" it up and out of ground effect was the key here. Again, I was surprised at how little stick input was needed. Now I'm getting more confident that the size of the a/c compared to the nano is what gives this the stability I'm seeing. That and the general genius of FliteTest, RTFQuads, MultiWii, RCExplorer, et al.

I didn't quite give it the full shake down test that cranial recommended -- that's for after I gain some more experience and skill / confidence. That said, I did want to test the yaw, roll, pitch channels a bit. So, I basically moved the sticks enough to see that they were responsive and didn't result in weird oscillations. I was particularly happy with how fine the resolution seemed as it didn't require a lot of movement to make small adjustments.

One more test. I decided to switch to angle mode while it was in such a steady hover. Well... that was surprising. As soon as I switched to it, it started a slow roll towards the right. As if I was giving it right cyclic. It stayed level, but just drifted right. Well, I immediately switched back to manual and flew it back to me and landed.

At this point, I was a little bit freaked out, so I disconnected the battery, stowed everything and walked back despite being in the air only three minutes total. I now have to either re-calibrate the accelerometers or just trim it out according to the multiwii guide (disarm, full throttle, and use cyclic stick to trim).

Anyway, I guess it's acro mode only until I can get the other modes to fly as steadily. Just to double check, when I got home, I connected it to MultiWiiConfig, powered up the TX and RX, and checked to make sure my switch / flight mode programming was correct. It was.

Anyway, thanks for all the help folks. I consider this a fairly good test. I learned a lot, and have a lot more to learn. The wind was picking up as I finished, so I'm not too fussed about having a short flight. Got 3.99V per cell in my 2200mAh battery after 3 minutes. At least I have a rough idea of how much flight time I can get out of the 2.2A packs.

Thanks again!
 
Last edited:

joshuabardwell

Senior Member
Mentor
In setting it down, I decided to reset the gyros once more (full left rudder/zero throttle + full up elevator/back cyclic -- ok, another question, when flying rotary wing, do people change terms for describing the channels / sticks?)

The terms used in quads are typically throttle, pitch, roll, and yaw. You don't have a cyclic because you don't have a collective pitch copter, so that term doesn't make sense.

There is not much point in re-calibrating the gyros manually most of the time. The FC automatically calibrates the gyros on startup, which is why it's important to have the copter stationary for ten or fifteen seconds (until the LED stops flashing) after powering up the board. Once the gyros are calibrated, there is not much that will throw them off. They are micro-mechanical devices, so a hard impact might throw them a bit for a loop, but in general, they'll be fine.

Remember that the gyro is different from the accelerometer. The gyro reports angular motion. The gyro is independent of any external reference frame, so as long as it is stationary when it is calibrated, it will always be "correct". The gyro is all that is used in Acro mode. It reports if the copter has changed orientation from the orientation you have set with the sticks, and tries to correct if so.

The accelerometer tells the FC how it is oriented relative to gravity. The goal of the accelerometer is to enable auto-level mode. So its goal is to return the copter to a level position such that the copter doesn't drift. So if that's the case, why is accelerometer calibration and trim required? Because "absolutely level relative to gravity" may not be the actual position where your copter hovers without drift. Maybe one of your motors is slightly angled or something.

So we regularly have to calibrate and trim our accelerometer to make autolevel work correctly, but we seldom have to calibrate our gyros.

I was also amazed and confused about the ability of this flight controller to allow for such a steady hover in acro/rate mode, so I'm assuming there is some self leveling that has to be happening here.

Nope. In Acro/Rate mode, all the FC does is maintain the copter's orientation. I think you are just seeing the difference between a large copter and a small one. Larger copters are much more inherently stable.

Nope... ok... acro mode, right?

Correct. If you center the stick and the copter holds its attitude, that's Acro/Rate. If it tries to return to level, that's Horizon/Angle.

I was particularly happy with how fine the resolution seemed as it didn't require a lot of movement to make small adjustments.

You may find that expo becomes useful as you get more aggressive with your flying. As I have gotten more experience, I have increased the rates on my FC, but also the expo. Originally I was flying at like 50% rate with 20% expo. Now I'm at 100% rate with like 55% expo.

One more test. I decided to switch to angle mode while it was in such a steady hover. Well... that was surprising. As soon as I switched to it, it started a slow roll towards the right. As if I was giving it right cyclic. It stayed level, but just drifted right. Well, I immediately switched back to manual and flew it back to me and landed.

You just need to recalibrate your ACC or use stick trim to fix this. But I second the advice from others to learn to fly in acro mode if you at all have the proclivity, as it will make you a much better pilot. Set up autolevel so that you can use it to save you if you are losing control, though.
 

cranialrectosis

Faster than a speeding face plant!
Mentor
Check all your nuts. Particularly check your motor mounts, prop nuts and any grub screws. :)

Re-calibrate ACC on a level surface. That should fix the drift in angle mode.

The first flight ever of an untested airframe is always a bit freaky. When that is also your first attempt to fly your own craft, it is doubly so.

Then again, that heart pumping rush is why we fly, isn't it?

Good job, makattack. :)
 

makattack

Winter is coming
Moderator
Mentor
Thanks CranialR,

Yeah, I rechecked the nuts, motor bolts, prop nuts and grub screw/collar on the tilt mechanism. All were still snug. I did recalibrate the ACC on a leveled table, initially, but after it was already mounted on the tricopter. I then realized maybe the flight controller/flip1.5 itself wasn't on a level surface due to my build -- with ziptied FT landing skids -- so, I put my mobile phone on top of the flip1.5 case with a level app running. I had calibrated it on that leveled table. I ended up having to shim it a little with some extra foam tape cut out and stuck into one corner. The tail motor is definitely tilted even with the servo at center point. That's necessary to overcome the yaw induced by the odd number (3) of motors and the fact that they are all spinning CCW props, in the same direction.

From MultiWiiConfig, I then clicked on the calibrate acc button, so hopefully, that will allow me to switch to acro mode without it drifting.

I will definitely follow all the advice about flying in acro mode to not overly rely on the sensors.

Because I've always sort of assumed accelerometers and gyroscopes operated on the same principal -- relying on gravity and momentum wheels, I never really looked into their differences until now:

http://www.livescience.com/40103-accelerometer-vs-gyroscope.html

So, that kind of makes more sense... but it does make me wonder if Joshua meant to say that the "accelerometers are used to indicate travel independent of gravity"

Anyway, I must have missed that the recommendation is to use horizon mode vs angle mode, which is considered deprecated/obsolete in multiwii. I'll know this software isn't updated much these days, and baseflight/cleanflight/naze is where all the action is. Maybe I just have to look in the code and changelogs to see what the story is...

http://www.multiwii.com/wiki/?title=Flightmodes

This is what makes this hobby fascinating and always a learning experience!
Dave
 
Last edited:

joshuabardwell

Senior Member
Mentor
From MultiWiiConfig, I then clicked on the calibrate acc button, so hopefully, that will allow me to switch to acro mode without it drifting.

In acro mode, only the gyro is used, not the accelerometer. So ACC calibration and trim should not affect acro mode at all.

So, that kind of makes more sense... but it does make me wonder if Joshua meant to say that the "accelerometers are used to indicate travel independent of gravity"

Nope. Gyros measure angular changes--rotations such as pitch, yaw, or roll. A gyro will measure exactly the same thing regardless of its orientation relative to a gravitational field. To make this directly relate to the FC, the gyro is used to detect and compensate for changes in the copter's orientation. The changes in orientation that are detected are independent of any external reference frame, such as the Earth's gravitational or magnetic field. They are relative only to the current position of the copter. So in acro mode, the gyro says, "The copter just rolled ten degrees to the right," and the FC says, "QUICK ROLL TEN DEGREES BACK TO THE LEFT", but the FC has no sense of whether the copter is right-side-up, up-side-down, or anything in between.

Accelerometers measure accelerations. To put it another way, if the gyro measures angular changes, the accelerometer measures linear changes--translations of the copter's position. So if you were to slide the copter to the left, the accelerometer would detect and report this. The reality is that angular movements also produce linear movements, unless the movement is centered on the accelerometer, so there is some interrelationship between the accelerometer and the gyro, but we can ignore this for the sake of discussion. The reason the accelerometer is necessary for autolevel is that gravity is experienced as a downwards-facing acceleration of 9.8 m/s/s. When you calibrate the ACC, it looks for what direction is pulling 9.8 m/s/s and registers that as "straight down". (This is an over-simplification, but go with it.) Then, while you are flying in an auto-level mode, it uses that data to determine its orientation relative to "straight down" and to do the appropriate thing in response to your inputs.

To go back to your statement, it's true that both gyros and accelerometers work outside of a gravitational reference frame. If you were on a rocket ship floating in space and you fired the rocket engines, an accelerometer would register that. The difference is that accelerometers measure the effect of gravity directly, while gyros do not. So a gyro can't be used for autolevel. Well... you could do a very bad kind of autolevel by doing some kind of dead reckoning with a gyro, but the drift in accuracy would accrue very quickly and make it ineffective.