Ok, that looks like a serious VESC bug… let’s take it to DM so that we don’t spam here.
Hey! Are there any pans to migrate this to float 2.0? Either way, I’m going to gibe the split Kps a go this weekend. Thanks for the innovation. I also found the roll to be too damped on my growler.
Something’s gonna be worked out, @surfdado has made it apparent he wants to transition to Refloat codebase. It’s just a question of what name it’s going to bear, and that has little practical impact for the users.
1 Like
I wanna give an update on @ednom3try’s controller.
We tried to debug it for a while, the controller was acting weird. At the beginning I assumed Refloat is messing with the package installation process, so we tried to make it not run Refloat after startup. This is normally possible, but the controller was not displaying running threads properly, would reboot on its own at certain points and the momentary button functionality seemed to bug out and play a role in this too. Ultimately, Refloat running or not didn’t seem to play a role in this, but it’s not conclusive due to the observed inconsistencies.
After some trial and error we found out the controller failed to erase (or, subsequently, write) the Lisp / main package code flash sector, and, when we resorted to attempting to flash the FW, the controller failed to erase the main FW flash sectors too. Strangely, it was willing to flash QML / App UI, and, it was working in the sense that it’d operate, Refloat was running and balancing.
Conclusion is the controller is semi-bricked and it looks to be a hardware failure. There’s nothing in the package that could really cause this. The controller was sent for RMA, I don’t expect to find out much more about the failure… 
This look promising !
I’ll give it a try next week on my Floatwheel. Anything particular to be carefull about ?
There are no known serious problems right now. If you have a flashed LCM that works with Float, it’s broken on Refloat right now, but @surfdado has already found the issue and the fix will be in the next beta release (ETA a few days).
2 Likes
Some feedback based on a few days of riding ~100km / 62mi.
The transition was completely seamless; it took me 4 minutes and kept all my Float package settings intact. I haven’t delved into the separate Mahony KPs yet, nor have I checked what the configuration is, so this could be a placebo effect, but I’ve noticed slightly better turnability and an overall smoothness in some contexts.
Waiting on beta 4 to have light control for floatwheel 
1 Like
I haven’t delved into the separate Mahony KPs yet, nor have I checked what the configuration is, so this could be a placebo effect, but I’ve noticed slightly better turnability and an overall smoothness in some contexts.
The defaults for the separate KPs are lower than Pitch KP, so you’re riding it already. Yes, better turnability should be the main effect…
Glad you like it!
A somewhat rare but potentially serious issue has been discovered with Refloat, which manifests in getting repeated errors when installing a new package (e.g. update Refloat or revert back to Float), or when uninstalling the package.
The issue is Refloat will not terminate itself correctly before the installation. Refloat does the same thing as Float in this regard, and there’s nothing apparently wrong, so something tricky is at play here and it will be difficult to tackle.
There’s a workaround, if you can’t get over the errors:
- On mobile: Go to the Terminal tab, tap
...and Reboot. - On desktop: Go to VESC Dev Tools → VESC Terminal, type
rebootwdtin the input text on the bottom and press enter.
Both of these will reboot your board in a way that Refloat doesn’t run, allowing you to freely install / uninstall the package.
If the package is in this errorneous state, it is also not possible to re-flash the VESC firmware, it’ll give an erase error instead.
There’s a potential nasty interaction with the Spintend Ubox controllers with a momentary switch. A user (reported a bit up the thread) had issue reinstalling the package, the controller would spontaneously reboot shutdown itself when attempting to install or uninstall the package. It was also not possible to use the above workaround, as instead of rebooting the way described, the controller would shut off. When turned on, Refloat would still be running and the issue would persist. I haven’t had further reports of this issue with Spintends, but be careful.
If you’re running a Spintend Ubox (with or without this issue), please let me know, it’d help me a lot to be able to correctly evaluate the situation.
EDIT: Correction, the Ubox controller shut it self off, not reboot, when trying to install/uninstall the package.
Beta 4 has been released with a handful of minor fixes: Release Refloat 1.0.0-beta4 · lukash/refloat · GitHub
This one will not reset your config if upgrading from beta3.
2 Likes
I’ve created a new thread for specifically discussion and news about the development of Refloat: Refloat development discussion
Right now there’s a plan to move Refloat into its own separate repo, any developers please follow that thread to stay up to date on what’s happening cheers.
Are all versions affected or only an older version of ReFloat package?
@riddimrider Also I added to FAQ how to update the package correctly with a tbc placeholder. Would be great if you or anyone else could add the correct steps.
Are those the correct step to update ReFloat to latest version correctly?
How to update Refloat to latest version correctly
- Tab “ReFloat Cfg” > Choose … at bottom right → “Save XML”
If Saving XML fails, you have to try connect from different device or via Desktop through TCP Wireless Bridge (see this thread) - Tab “Packages” > Uninstall Current
- Tab “Packages” > … > “Install from File” (get latest release here)
- Tab “ReFloat Cfg” > Choose … at bottom right > “Load XML” > pick the saved XML from step 1
Step 2. (Uninstall Current) is not necessary, otherwise these are the correct steps for mobile.
I’ll add these to the readme (and make it easier to find) once I get to moving the github repository, haven’t gotten to that yet.
Are all versions affected or only an older version of ReFloat package?
All versions of Refloat are affected by the “Unable to upgrade / uninstall Refloat” bug, it hasn’t been fixed yet.
1 Like
I try to build that package but i got error below :
arm-none-eabi-gcc -fpic -Os -Wall -Wextra -Wundef -std=gnu99 -I…/…/c_libs/ -I…/…/c_libs//stdperiph_stm32f4//CMSIS/include -I…/…/c_libs//stdperiph_stm32f4//CMSIS/ST -I…/…/c_libs//utils// -fomit-frame-pointer -falign-functions=16 -mthumb -fsingle-precision-constant -Wdouble-promotion -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mcpu=cortex-m4 -fdata-sections -ffunction-sections -DIS_VESC_LIB -DUSE_STLIB -I…/…/c_libs//stdperiph_stm32f4//inc -MMD -flto -c torque_tilt.c -o torque_tilt.so
In file included from torque_tilt.h:21:0,
-
from torque_tilt.c:19:*
conf/datatypes.h:37:14: error: expected ‘{’ before ‘:’ token
- typedef enum : uint8_t {*
-
^*
conf/datatypes.h:40:3: warning: data definition has no type or storage class
- } LedPin;*
- ^~~~~~*
conf/datatypes.h:40:3: warning: type defaults to ‘int’ in declaration of ‘LedPin’ [-Wimplicit-int]
conf/datatypes.h:42:14: error: expected ‘{’ before ‘:’ token - typedef enum : uint8_t {*
-
^*
conf/datatypes.h:75:3: warning: data definition has no type or storage class
- } LedColor;*
- ^~~~~~~~*
conf/datatypes.h:75:3: warning: type defaults to ‘int’ in declaration of ‘LedColor’ [-Wimplicit-int]
conf/datatypes.h:77:14: error: expected ‘{’ before ‘:’ token - typedef enum : uint8_t {*
-
^*
conf/datatypes.h:83:3: warning: data definition has no type or storage class
- } LedMode;*
- ^~~~~~~*
conf/datatypes.h:83:3: warning: type defaults to ‘int’ in declaration of ‘LedMode’ [-Wimplicit-int]
conf/datatypes.h:85:14: error: expected ‘{’ before ‘:’ token - typedef enum : uint8_t {*
-
^*
conf/datatypes.h:90:3: warning: data definition has no type or storage class
- } LedTransition;*
- ^~~~~~~~~~~~~*
conf/datatypes.h:90:3: warning: type defaults to ‘int’ in declaration of ‘LedTransition’ [-Wimplicit-int]
conf/datatypes.h:94:5: error: expected specifier-qualifier-list before ‘LedColor’ -
LedColor color1;* -
^~~~~~~~*
conf/datatypes.h:113:5: error: expected specifier-qualifier-list before ‘LedTransition’
-
LedTransition headlights_transition;* -
^~~~~~~~~~~~~*
conf/datatypes.h:134:5: error: expected specifier-qualifier-list before ‘LedPin’
-
LedPin pin;* -
^~~~~~*
make: *** […/…/c_libs/rules.mk:58：torque_tilt.so] error 1
Can anyone help me?"
You need gcc 13 (arm version).
A new beta is out:
It won’t reset your config if upgrading from beta3 or beta4.
It should have the uninstall bug fixed and everything should work fine now. If installation issues persist for anyone, please let me know!
Thank you your reply , What version arm-gnu-toolchain are you using .
One thing I’ve noticed is that no matter how perfect your calibration is, there seems to be slight variance in the interpreted orientation for low Mahony KP (e.g. 0.4) and high Mahony KP (e.g. 2.0).
This is no issue when switching to Refloat with an already calibrated IMU. However, if you recalibrate your orientation once your Mahony KP and Accel Conf Decay have been changed by Refloat, you’re calibrating with respect to Mahony KP 0.4, which could result in a slightly skewed level angle for actual balancing at Mahony KP 2.0.
For now, I was able to resolve this by manually changing my Mahony KP and Accel Conf Decay in App CFG before doing IMU Calibration, and making sure not to touch Refloat CFG in the meantime. And then when done, hitting write on Refloat CFG to have it automatically reset my Mahony KP and Accel Conf Decay back to 0.4 and 0.1 respectively.
But this isn’t quite ideal from a user experience. Should we have a sort of mode switch that reverts your App CFG to match your Refloat CFG IMU settings for calibration purposes? Maybe it could be combined with the Disable Refloat toggle into a general “calibration/maintenance mode”?
Do we have any idea why there is this difference in orientation?
When I look at my pitch in Refloat App UI, it matches the balance pitch. Or, in Float terminology, true pitch matches pitch (sorry about the confusion I introduced 
). I recall one occurrence when these didn’t match in a stabilized board position, but don’t remember the circumstances anymore, didn’t have a chance to investigate (IIRC it fixed itself after a reboot).
As long as pitch and balance pitch are the same in a steady state (which they really should be), different KPs give the same orientation, indicating the calibration itself gives different results for different KPs and that’s likely a bug?
Even if this would be some peculiarity of the calibration that can’t really be fixed, it would be better to still handle this workaround inside the calibration if possible (e.g. by setting the KP which gives the correct result for the calibration).
1 Like