[mr_w]

I have 250 size tricopter, CC3D, 2204 2300KV readytosky motors, blheli esc (modded 30A generic simonk / added external osc), which can take off and fly, however shakes like it has extremely unbalanced blades.

On the other hand, if I load TauLabs fw, it flies perfectly stable.
Both setups are similar, all stock settings.

I'm attaching both uav files so if anyone could compare (given how much the code from two has deviated I haven't still figured out what exactly to compare) and find out what is causing it to shake, as I'd like to switch to LP.

[f5soh]

Try reducing the Yaw mixer slider (vehicle tab) to something about 50%
Current default Yaw Pid are too high for a tricopter.

[mr_w]

Hm, changed to 50%, but still no joy.




On the side note, it seems that I cannot enable flight side logs from GCS, all the options are disabled. Was that done on purpose, or is just a bug?

One more thing, not sure if relevant - MPUGyroAccelSettings has GyroScale locked to 2000. I can change and "upload", but the setting does not persist. Tried with Scale_500 (TL uses 500) but after reboot, it was back to 2000.

[f5soh]

I can see the major oscillation is on Roll axis.
TL PID default settings are very low, try reducing also the Roll PID settings on Stabilization tab.

There is no issue with Gyroscale saving, maybe you forgot the button ?


CC3D do not support logs, if you want logs you need a telemetry link.

[mr_w]

It seems that I've used the other "UP" button Thanks for that tip.

Decreasing roll pid values to match TL settings did the trick! There are no more vibrations, but I had to bring back Yaw mix to 100%, as at 50% it was yawing CW and I had to constantly correct it.

Regarding the logs, I have just added bluetooth module to mainport and set it telemetry, 56k. This works, but not as smooth as with USB - especially the settings tabs. Telemetry data works nice and fast, but I settings are sometimes retrieved and sometimes not. Is there a way to make it work smooth as with usb connection?

[f5soh]

Run higher baudrate give better results but currently in 15.09 telemetry is hardcoded to 57600bauds.

[mr_w]

Run higher baudrate give better results but currently in 15.09 telemetry is hardcoded to 57600bauds.

I did eventually find out that baud rate is hardcoded.

Which brings me to another question - building from source, what should I prefer for messing with - rel-15.09 or next?

I did have trouble building fully functional GCS, that is on OSX 10.10, while firmware is no problem.

[f5soh]

You can use the Next branch and find new features

I have no experience using Osx.
Whats the error ?

[mr_w]

OSX GCS build works fine when started from build directory, but I cannot make working package and transfer it to another computer ( I have couple of other locations / computers where I need it ) because Qt doesn't get deployed correctly.
I think this part of the build has to do something with it, where it fails to call macdeployqt

....
Qt library directory is "@rpath/"
Running macdeployqt from @rpath/../bin/macdeployqt
/Users/mr_w/Desktop/librepilot/package/osx/libraries: line 28: @rpath/../bin/macdeployqt: No such file or directory
....

I suppose @rpath is not what Makefile and/or build scripts are expecting to get, but .. it tries to get Qt SDK folder by greping through otool output, like this:

Code: [Select]

[mr_w@macbox librepilot]$ otool -L build/librepilot-gcs_release/LibrePilot\ GCS.app/Contents/MacOS/LibrePilot\ GCS
build/librepilot-gcs_release/LibrePilot GCS.app/Contents/MacOS/LibrePilot GCS:
@executable_path/../Plugins/libUtils.1.dylib (compatibility version 1.0.0, current version 1.0.0)
@executable_path/../Plugins/libVersionInfo.1.dylib (compatibility version 1.0.0, current version 1.0.0)
@executable_path/../Plugins/libExtensionSystem.1.dylib (compatibility version 1.0.0, current version 1.0.0)
@executable_path/../Plugins/libAggregation.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1256.14.0)
@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.5.0, current version 5.5.1)
@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.5.0, current version 5.5.1)
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.5.0, current version 5.5.1)
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
@rpath/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.5.0, current version 5.5.1)
@rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.5.0, current version 5.5.1)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

This seems to be the line..
QT_DIR=$(otool -L "${APP}/Contents/MacOS/${GCS_BIG_NAME}" | sed -n -e 's/\/QtCore\.framework.*//p' | sed -n -E 's:^.::p')

but now when I think of it, I could just use known QT_DIR and not rely on otool|sed magic.

[mr_w]

Now when my pids are so-so tuned up and this tri flies quite nicely, could somebody just explain what is the actual relation between Rate PID and Attitude PI values when flying only in Attitude mode? I can see from GCS that one is Inner and other is Outer loop, but it wasn't quite obvious that Rate P value would affect Attitude mode at all, yet alone that much.

[f5soh]

All stabilization modes uses the Rate (inner loop), except "manual" or Acro+ at full stick.

In attitude the Outer loop add a second parameter based on accelerometers and stabilization desired (bank angle desired)

https://www.youtube.com/watch?v=U3yHz3phdb4&feature=youtu.be&t=23m12s