Tricopter Headfree mode oddities

[jgrouse]

Hi,

I tested out the Headfree mode with Level and Mag active at the same time and it certainly seems to do as it was intended. The only strange thing I'm seeing is that when the Tricopter is tail in there is no drift. If I then rotate the Tricopter 180 so it is nose in it wants to drift left quite dramatically. As soon as I spin it back to tail in the drift left is gone. It's like the trimming I have applied is not translated correctly depending on the direction it is pointing. Being a tricopter with all CCW props it does need to be trimmed to the point where you can see a visible tilt to stop it drifting so possibly the headfree calculations were based on the craft being perfectly level with the horizon rather than on a slight tilt? Bit of an irritation, however it would be nice to know if this is something that could be corrected in the code? I'm planning on moving to a Y6 however I'm curious if anyone else has seen this with their Tricopter in Headfree mode?

Should add that I'm testing with the V2 dev 20120606 code.

[wilco1967]

I also noticed the level trim seems to stick to the magnetic heading, rather than the copter's front.....
Never flew in headfree mode, but it also happens to normal level mode....

Normally I never had to use the level trim, as my tri tracks pretty straight as is.
However last week, I had a crooked motor mount (now straightened), and that's when I temporarily dialed in some level trim when I noticed the same as you describe.....

For example: When trimmed to level while facing north, it might need to be leaning a bid east to stay in one place (no wind effect, just crooked copter).... when yawing around, the copter keeps leaning in the east direction, and not to its own right (which will have become west when pointing south).

Lessen learned.... make sure everything is as straight as possible....
Other leason learned.... seems something wrong in cond on how level trim is accounted for.... Don't use it, but fix your copter so you don't need it.

BTW... did anyone notice differences in flying behaviour between EOSBandi R33 GPS code, and the current 20120606 dev ?
I might have just imagined it, but my feeling is the R33 was significantly better in RTH / PH as the 20120606 dev, with identical settings.... I even went back to the R33 to try, and that is pretty much perfect....
might have been my crooked motor mount that was acting up though.... I fixed it the same time as rolling back to R33
Not a very scientific approach I admit....
Will try again with dev20120606

[EOSBandi]

which gps? i2c or serial?

[Alexinparis]

another question:
in LEVEL mode, do you use your transmitter trim, or the multiwii level trim (via stick combination) ?

[wilco1967]

another question:
in LEVEL mode, do you use your transmitter trim, or the multiwii level trim (via stick combination) ?

which gps? i2c or serial?

Not sure whom you're asking.... but if its me....

- I'm using multiwii level trim..... (transmitter trims always centred around 1500)
- Serial GPS on a Flyduino.... (working perfect !).

[EOSBandi]

I also noticed the level trim seems to stick to the magnetic heading, rather than the copter's front.....
Never flew in headfree mode, but it also happens to normal level mode....

Normally I never had to use the level trim, as my tri tracks pretty straight as is.
However last week, I had a crooked motor mount (now straightened), and that's when I temporarily dialed in some level trim when I noticed the same as you describe.....

For example: When trimmed to level while facing north, it might need to be leaning a bid east to stay in one place (no wind effect, just crooked copter).... when yawing around, the copter keeps leaning in the east direction, and not to its own right (which will have become west when pointing south).

Lessen learned.... make sure everything is as straight as possible....
Other leason learned.... seems something wrong in cond on how level trim is accounted for.... Don't use it, but fix your copter so you don't need it.

BTW... did anyone notice differences in flying behaviour between EOSBandi R33 GPS code, and the current 20120606 dev ?
I might have just imagined it, but my feeling is the R33 was significantly better in RTH / PH as the 20120606 dev, with identical settings.... I even went back to the R33 to try, and that is pretty much perfect....
might have been my crooked motor mount that was acting up though.... I fixed it the same time as rolling back to R33
Not a very scientific approach I admit....
Will try again with dev20120606

Just tested the 0606 code with an i2c_gps based copter, and it's working perfectly....
(you have to apply the gps related change in revision r920)
Right now, I'm building a copter for serial gps tests...

[wilco1967]

I'll give it a try with the r920 patch..... But it will have to wait until next weekend before I get an oportunity,,,

Thanks a lot !

[Alexinparis]

BTW... did anyone notice differences in flying behaviour between EOSBandi R33 GPS code, and the current 20120606 dev ?
I might have just imagined it, but my feeling is the R33 was significantly better in RTH / PH as the 20120606 dev, with identical settings.... I even went back to the R33 to try, and that is pretty much perfect....
might have been my crooked motor mount that was acting up though.... I fixed it the same time as rolling back to R33
Not a very scientific approach I admit....
Will try again with dev20120606

Hi,
I hope it's not confirmed, but a bug is still possible
The code of dev20120606 (or dev20120618 ) and r33 should give the same result regarding the behavior with serial GPS (and also for I2C GPS).
The code was a little reduced, but the result should be identical. I'm interested in having more feedback.

[wilco1967]

I also noticed the level trim seems to stick to the magnetic heading, rather than the copter's front.....
Never flew in headfree mode, but it also happens to normal level mode....

Normally I never had to use the level trim, as my tri tracks pretty straight as is.
However last week, I had a crooked motor mount (now straightened), and that's when I temporarily dialed in some level trim when I noticed the same as you describe.....

For example: When trimmed to level while facing north, it might need to be leaning a bid east to stay in one place (no wind effect, just crooked copter).... when yawing around, the copter keeps leaning in the east direction, and not to its own right (which will have become west when pointing south).

Lessen learned.... make sure everything is as straight as possible....
Other leason learned.... seems something wrong in cond on how level trim is accounted for.... Don't use it, but fix your copter so you don't need it.

Just tested the 0606 code with an i2c_gps based copter, and it's working perfectly....
(you have to apply the gps related change in revision r920)
Right now, I'm building a copter for serial gps tests...

Update.....

I think I finally found out what was causing this problem before.
Today it happened again, but this corresponded with the mag having lost its calibration. Not sure how that happened (thats another thing I need to figure out), but while the mag was wrong, I noticed the same level mode trim behaviour as before....

So I guess when it happened before, It was one of those times mag calibration was lost....

Could using a wrong version (dev0622 versus dev0618) of the GUI, and then performing a write overwrite the mag calibration data ?
If i do a mag calibration from GUI, and then do NOT press write, all seems fine (also after power off).

EDIT
Finaly found out what caused my mag problems.....
seems like there was an intermittent wiring issue with the 5883 I2C connections..... normally, all would work, but vibrations would cause an intermittent fault (cold solder joint)... did not see it when connected to the gui, but when tapping the connection, I could produce I2C errors.... too much errors, and the 5883 would stop responding completely...
After landing, and re-calibrating (less vibrations), it would usually work again for some time, before quiting again....

Difficult to distinguish between software induced 'features' that might be introduced of every new software release, and some intermittent hardware issue....
Anyway.... this was a hardware issue.