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.
Ok, so this took quite a bit longer, apologies, everyone.
GitHub - lukash/refloat: VESC package for self-balancing skateboards. is now effectively a new repo, the old one as been renamed back to vesc_pkg (as it is originally a fork of GitHub - vedderb/vesc_pkg: Official VESC Packages). There’s a branch called refloat-old there which is the old main if anyone would be looking for that.
In the new repo, main now contains a stand-alone and self-contained Refloat package (it has its own c_libs, which I’ve named vesc_pkg_lib (and it’s a git subtree of GitHub - lukash/vesc_pkg_lib: VESC Package library containing the necessary files to build a VESC Package.).
I also apologise for any inconvenience this causes to anyone who has based some significant amount of work on top of the old structure, but now the repo is clean and will be much easier to work with.
I’ll be making another beta release (hopefully the last one), the tag is there but my CI/CD is acting up right when I need it, I’ll wait a bit and hope it’ll start working.
Alright, had to rework the GH Actions some more, now it should be all good.
@siwoz the config signature is now automatically attached to each release, check the latest one: Release Refloat 1.0.0-beta6 · lukash/refloat · GitHub