This should be interesting

Chris,
I remember your post about the gps, hence my comment about possible wire snafu’s. I’m going to the supply house to see if i can source some flat 8 wire cat5e cable or similar to redo the extension, and i have a couple data sheets for pixhawk 2.1, i believe it has the pinout in there, ill have to look when i get back.
Tim

Alright, so i took apart the cable i extended. I color matched the wires correctly. Unfortunalty, i dont know what color wires correspond properly to the pins on the pixhawk from the Here.
Colors are, black, brown, red, orange, yellow, green, blue, purple in that order on the factory connector.
I have a spec sheet that calls out the pinout but not the color code of the Here.

It goes, +, TX, RX, SCL, SDA, SFT, LED, -

Tim

I guess if those specs are not available for the Here, I’d take it apart and reverse engineer it and figure it out. It can’t be anything all that special. Just a uBlox GPS receiver, mag chip and button built into it. The power, tx, rx and ground are for the GPS. The SCL and SDA are the mag chip. The SFT is the button.

Failing that, contact the manufacturer of it. It obviously has a problem of some kind.


This might help

I cracked open the “Here” GPS. Unfortunatly the screen printing on the board is using different nomenclature than the Pixhawk unit. It is listed TP1-TP7. There are not 8 contact pads on the board, there are 8 wires on the connector though @ both ends.

That being said, " I learned a valuable piece of information today!" I brought the heli outside to see if not getting a quick GPS lock had something to do with it, no dice. BUT, I found that if I “Power up the Pixhawk first, then plug in the servo rail after it is done booting, the switch light on the Here stays steady and it works as it should”?

I moved the servos for maybe 5 minutes, picked the heli up and shook the crap out of it, moved the servos again and could not get the swash to lock up and have the safety switch light flashing.

So for whatever reason, if I power the receiver and servos first, it locks up the swash when it boots and the safety switch will start flashing and I cannot press it to re-arm it.

Tim

This might be it.
From what I read about Pixhawk 2.1, it will not fully function when powered by servo rail. It will only function as “RC-passthrough” (directly send PWM from receiver), automated function such as autopilot, loiter, position estimator etc will not work.
I guess safety-switch gets bypassed in this state.
Now when you power up the system(with USB or PM), safety-switch starts doing its job and kills PWM generated by RC-passthrough. This causes servos to lock up at extreme and stop responding.

Okay, so im slowly working through issues and such, so far so good, i appreciate all the help and ideas!
Today, on the bench in stabilize, i noticed that when i move the cyclic the rudder also moves. Is this normal behavior? Some form of compensation?
Secondly, i saw a piro-compensation parameter while going through everything. Is this being used by everyone?
Thanks again,
Tim

From my experience with other FBL unit (Skookum 720), it has cyclic compensation along with collective compensation.
It acts similarly to collective compensation (H_COL_YAW parameter) but I don’t know if what you saw related to this.

Piro compensation, unless you are going to spin your heli, is not important.

From my experience with 3.4.6, this appears to be normal behavior. The other thing you may notice when moving the cyclic with the aircraft on the bench is that if you move the cyclic to an extreme and leave it there you’ll notice the swashplate will flip to the other side after a second. This is normal also. The swashplate is responding as designed. Many would not consider this a desired behavior but the system is working as designed. This has been griped but I’m not sure it’ll get fixed for traditional Heli as it is not considered a problem for multi rotors. I am working with Rob to get a fix for the traditional Heli frame.

Pitt,
Ive used quite a few different fbls, Skookum not being one, as of now, lost count, and on the bench, not a one of them demonstrates a link between the collective, cyclic and yaw. That totally doesent mean there isnt any link, ive changed many different forms of patameters relating to just that, it just acts very difterently on the bench/ground vs flying. All part of the code involved for sure.
Not knowing exactly how Pixhawk is supposed to behave on the bench and in the air is the reason for my question.
As to piro comp, i understand its purpose very well, once again, i just do not know how it behaves with Pixhawk and if its being used and works as it should?
Tim

Bill,
Thanks for the info, i remember reading a thread about that awhile back. There definatly seems to be some differing opinions on how it should act. I understand both sides a little, but personally believe at least where helis are concerned, if it were set up to behave more like a traditional fbl it might be more attractive for people.
I get they both have very different purposes, but industry wide people are used to the behavior of units like the BeastX, Bavarian Demon, Spirit, VBar etc, and it would likely get alot more people using the system if the basics could be made easier with defaults and the behavior on the ground and in the air was also more fbl like.
Lots of people have been taught to check their helicopters by moving the swash to extremes of cyclic and collective as well as yaw before lifting off, and by the sounds of what im hearing that could cause some issues if held in extremes for too long.
I just truly believe modeling some behaviors of the 3D fbl units would increase the adoption rate with Pixhawk, and that always translates for more money for the cause?
I have quite a few conversations going on at a couple different forums regarding this build and although quite a few people are interested in the Pixhawk, the general consensus seems to be that its voodoo magic and few people get it working correctly.
As ive said before, im partial to helicopters so its all moot in my case, ill get this working and flying well if it takes months.
Im getting very close to the tuning battle it seems, lots of permanent wiring and a 200amp Mauch sensor to be done first, but in the meantime im trying to absorb as much information about the proper use and behavior of the Pixhawk before the blades ever spin.
Really working on trying to learn proper log reading as well, chasing down different patameters and values and their meaning as it pertains to the Pixhawk.
Tim

It’s somewhat normal to see the rudder servo move, if you give cyclic input, in Stabilize mode.

What has to be understood, is that all of the stick commands in Stabilize mode, are done in the earth frame. Not the body frame that you are used to with FBL systems.

For example, if you take the heli, and pitch it nose straight down, and give a yaw input, you will actually see lots of roll servo movement, and little yaw servo.

If you take the helis, and roll it on it’s side, and give it yaw input, you’ll see the pitch servos move, not the yaw servo.

When you give it yaw command, it tries to yaw about an axis straight up from the earth, NOT the helicopter’s current body orientation.

The same is true for all axis.

If the heli is sitting on the table, and you give it roll, and you see the yaw servo move a bit, it’s because the heli must not be sitting perfectly level. This is normal. It’s fine in the air.

PiroComp does work, I use it on my Goblin 380. (At least, it works on AC3.3, haven’t really tested it for 3.4 yet). What it simply does, is rotate the wound-up I-terms from roll and pitch as the heli yaws around.

Let’s say you are flying fast forward and level. The system will build up some pitch I-term necessary to keep the disk from blowing back in the wind. If you really quickly yaw it around so it’s travelling sideways, the PiroComp will rotate the built up I-term around so that the disk is tipped a bit to the side.

IMO, multirotors should have this function too, as they have an even stronger blow-back force that helicopters have. In fact, it’s even worse. But he disagrees with the mechanism. I think the fact that multirotors yaw so much slower than helis, and also that not that many people are sport-flying with Ardupilot are why it hasn’t been a big issue.

Oh, and Tim, it sounds to me like you’re having some hardware issues, or some deep code issues. You should try to talk to Philip Rowse or maybe Randy or Tridge about that.

You need to be able to figure out how to reproduce the issue, though, before they’ll bite. If it’s seemingly random, and you’re the only guy seeing it, it’s hard to get their attention.

Rob,
Thank you for the response. I do have a couple repeatable issues still, and this evening i have every intention of doing a short video along with a log .bin and a parameter file. Hopefully that helps?
Im also going to re-read my own thread and see if i missed anything as well.
As ive said on quite a few occasions now, this is all exacerbated by the fact i am so unfamiliar with the Pixhawk unit and enviornment, and me being me, deceided to go with a new unit vs a proven one. :confused:
I am slowly getting a picture of how this unit and firmware is supposed to act, and its responses like yours, Bills, Pitts and Chris’s that are adding peices to the puzzle.

Tim

Tim, the two are designed for different purposes and can’t be compared. Something like 99% of the RC helicopter business is all about the 3D rage - faster, quicker, more headspeed, more power, wad 'em up every 7-8 flights and go get the spare. The primary activity of every 3D heli pilot in our RC club is crashed helicopter rebuilding and arguing about who’s got the best FBL unit.

The ArduPilot system was designed as a commerical-grade autopilot for unmanned vechicles. Which is a fundamentally different mission. It does not surprise me that most RC helicopter people would consider Pixhawk to be voodoo magic. Because out of all the 3D pilots in our club there’s not a single one of them that actually know to fly a helicopter with any amount of smoothness or precision in scale flight. All they know is full-stick 3D and countless hours spent tuning expos and rates and mixes in the radio in between crashes and helicopter rebuilds.

Chris,
I understand the differences in usage, not suggesting changes to make it fly like a VBAR, im more thinking cherry picking the best, most useful parts put of an fbl and somehow making available default tuning and more resiliant setup procedures that result in a least a flyable model out of the gate.
Take for example the Spirit FBL, even though it uses accelerometers, the rescue feature is all but bullettproof and knows where level is no matter what, even after an insane 3d flight. And thats basically a hard mounted unit with one layer of VHB tape. Somehow incorporating that sort of vibration resistance would be a benifiet i think, and a unit like that has access to far fewer sensors than a Pixhawk.
Now i know ive read about cases where people have gotten great flying heli systems with a pixhawk, but disproportionately, ive read of many cases where people could never get rid of ossicilations, or it just plain crashed on the first go and they never looked back.
If there was a template per se’, defaults, that had usable PID’s for most helis, and a setup procedure that was more tailor made for helicopters, i think it would be a huge improvement for traditional heli. I get that the tools are there to make it fly already, but making it more approachable would only increase the user base especially with traditional heli.
As ive said before, FBL companys have really nailed getting something in the air even in the face of poor setup and it could be the biggest vibrating mess in the sky but somehow it still flys good and knows where level is after a 3d flight.
I have know idea what filters they are using, or what algorithms? Something they are doing though works, and works well. That would be a valuable addition for traditional heli i think.
I know personally, im going to work through whatever i need to to get this project where i need it to be. But after going though a basic setup for the very first time, im just offering my observations and regurgitating the feelings from some other threads im apart of.
Tim

I just chuckle because it’s all marketing on the part of the heli manufacturers. Including the FBL rage. Fact is, the old flybar beats any of 'em for stability under all flight conditions and speeds. FBL is great for the 3D crowd. Lot less parts to replace when they wad 'em up. That’s always one of the big selling points :fearful:

Same with tail drives. Belt drive tails were used since the first RC heli’s flew. Then the heli manufacturers managed to convince everybody that torque tube drive, despite the fact that they are noisy, fragile, vibrating contraptions, are “better” and more “efficient”. Well, I got news for 'em - changing torque directions twice is not more efficient than a belt. It’s all marketing. And now guess what? Align is building some of their latest heli’s with belts again because they’re smooth, quiet and reliable.

Chris,
Oh, I don’t doubt the proven fly bar system. It just works, in fact many people at my field still swear by them… I’ts not uncommon to see 50% fly barred models some days. When I mention the newer FBL controllers, its more about the rescue features based on accelerometers they are leveraging these days. That particular technology has made enormous improvements even in the last year or two.
What i’m getting at is pretty much every flight mode on Pixhawk uses some form of added stability in the code and whatever some of the FBL companies are doing to filter out the noise and get a perfect horizon every time would be valuable to the Pixhawk environment.
It’s evident some companies have better code than others as they are not all even remotely equal. The Spirit FBL in particular has proven to be incredibly stable with an accurate rescue or stabilized flight mode no matter how much vibration is present. Keep in mind I am totally not in any one camp brand wise or am I even campaigning for Spirit, i’m just noting my recent experience with them after having some less than perfect units. I put one on a heli that vibrated like a flying roto-tiller and it still functioned as good as the one on my electric 700x 3D screamer.
It’s funny as I’ve never actually used the rescue or a stabilized mode on my 3D helis, I just test it occasionally after a flight and tried out the stabilized mode to see how well it worked as I’ve had FBL’s that did some awful stuff when you flipped the switch in the past. Things you’d expect when the horizon is lost and it thinks up is down. :confused:

Trust me Chris, I totally understand the industry is based largely on hype trains and snake oil, but occasionally a company here and there has a genuine advancement the could be put to use elsewhere.

In some ways, I do enjoy the simplicity of a pure FBL head exactly because of “the lower parts count”. Not from a crash cost perspective, but from a maintenance stand point. I’m going to put my best foot forward and see if I can get this 800 FBL heli off the ground with Pixhawk 2.1. That being said, I am eyeing a trex 700 fly bar a pilot at our field has for sale as another project with a Pixhawk as well. “Spurred by a lot of things you’ve said championing them.”

As to torque tubes, I agree they are inherently nosier and more vibration prone than a belt drive. I spent many hours over many days getting the tail drive on my 800 somewhat smooth. Helical gears and lots of shimming with that “perfect gear lash” was key for me. I’m sure way down the roads i’ll be employing a direct drive tail if I have issues with vibrations, but for now I hope it will do. I wish Align would come up with a belt drive “upgrade” as they call it for my heli.
Tim