A thread for general information about the Refloat package development, news about what’s happening development-wise etc.
Short to mid term plan of the project side of things:
So, after some discussion with Ben Vedder I’ve decided to move Refloat to its own separate repository. The rough plan is as follows:
refloat repo (back to) vesc_pkg, as it is a fork of that, and I’ll need that fork.vesc_pkg_libs, which will contain the shared part of vesc_pkg, the c_libs.refloat, and move the Refloat code itself into it, directly into the root directory.
vesc_pkg history, meaning along with the move, this will cause any code based on my repo now to not cleanly transfer (rebase) to the new tree. I’m hoping this is alright at this stage, if anyone (that I don’t know about) has anything significant already based on top of Refloat, let me know, I can help transfer the history cleanly if needed.vesc_pkg_libs will be integrated into refloat via git subtree.refloat will be integrated into vesc_pkg also via git subtree, and releases to VESC Tool Package registry will be done via this avenue (posting a PR with a git subtree update to the repo).vX.Y.Z instead of refloat-X.Y.Z.The plan is to do this in the next few days…
Let me know if you ever decide to publish the generated files as part of the release process so I can add support to Floaty 
Does Floaty support depend on that? What was it that you needed? Just the signature or more? I’m still not convinced they should be part of the release…
What would be your process of getting the data you ask for and using it? Automated or manual? I’m trying to think of the best solution…
For tuning it does, yes. Right now I have a script that takes a list of commit hashes and generates all the static types, defaults, etc from settings.xml, confparser.h and conf_default.h for each version. It should be easy enough to adapt to the script to use a published release artifact if none was available with each release.
For tuning it does, yes.
The question actually was: Does Floaty support depend on me publishing the artifacts? 
But I understand without the generated sources in git you’d have hard time getting the data you need, so I’ll infer the answer to that question is also yes 
… from settings.xml, confparser.h and conf_default.h …
What do you use from those files? I’m certainly not going to attach all sources generated by the config generator to the release. I can understand needing the signature (which is generated), the rest of the data should be in settings.ini?
I’m coming around thinking the release artifacts is likely the best place available to put this, assuming I can hook it up to be done automatically (should be possible, along with the package build). But I wanna keep it as simple as possible, ideally there’ll be one file called config_signature.txt containing just the signature.
First of all i love the feel of my board now and I’m quite sure this is the way. I do wish that I could ramp my brakes up even more because it stops at 2.0. anyway good job guys .
Main issue is going too high on Angle P or Rate P (which high Brake Scaling effectively does unless your base Angle/Rate P is tiny) can start to cause negative side effects in the form of vibrations (mostly a side effect the high Mahony KP we use).
If you feel the need to push the brake scaling that aggressively, I would suggest giving Torque Tilt Strength (Regen) a shot. It’s by far the most effective way to aggressively strengthen the brakes on the high Mahony KP tunes we run nowadays, as its effect recursive in a way and gets stronger and stronger the longer and harder you brake. 0.10 degrees / A is a good starting point, and bump it up .05 at a time if you need more.