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
A “software-only” alternative to footpad sensors
Acceleration (going straight dZ=0) obviously requires the most power with a person standing on the board.
But there are other cases to consider…
From a perspective of Potential and Kinetic energies, in theory it should be possible to detect whether a person is present on a board or not - in software only.
Power is the rate of change of Energy, mathematically speaking, Power is the time derivative of energy expressed as:
P = dE / dt
Some physics
Mechanical Power
We assume that we know the weight of the board, and the weight of the board with a driver.
The Kinetic and Potential Energies are calculated from IMU data (maybe combined with vesc speed info). Then we get the mechanical Power by dividing the increase in total energy by the timestep dt (the chosen evaluation time window).
Finally, there are power losses due to friction, heat, etc. It should be possible to roughly estimate these. Except head and tail wind resistance (for that we need the weather conditions 
).
Electrical Power:
The electrical power is simply the Wattage used by the Vesc (voltage x ampere) averaged over the chosen timestep dt.
Detecting run-away state:
BY comparing the Mechanical and Electrical Power numbers, one should be able to determine if we have a run-away board (no person present).
There is a huge margin, because the weight of the board with a person is many times larger than the weight of the board only (I guess).
What have I forgotten? Are there other things the footpads are used for?
- Couldn’t the “Power Up” state be determined by observing IMU data?
- Obviously, you need to turn off the board when transporting it (when not riding it).
Interesting idea, but I think it’ll “just fail” in many situations, one example for all is going slight downhill, which makes the consumption the same as if there was no rider on the board. Maybe this can be handled in some clever way, but I doubt it can result in something usable and safe. If anyone wants to analyze this and test it out, they’re very welcome though
A new beta is out! Release Refloat 1.0.0-beta6 · lukash/refloat · GitHub
Unless something unexpected pops up, this will be the last beta before the final release.
Been riding this the past two days… wow it’s amazing. Can’t pinpoint what it is but mission clone feels much more like a mission or mission plus only thing I noticed is I went back to float so for minute to load different loads to my spots thinking they would carry over and they didn’t which was fine cuz I figured out t you can pull up standard issue tunes by pressing top right corner of tune box. Even coming out of nose drags was alot better. Board didn’t feel sloshy when coming out of them. Ran one of my fastest underground times with it as well. Any questions lmk I’m going to ride the shit out of it daily
2 Likes
-
The “downhill runaway state” is why “losses” in the system are important to consider. A board running downhill with a person standing on it, will have much more momentum than the board alone. If there is no electrically applied torque, the downhill acceleration, is only caused by conversion of potential energy to kinetic energy. Due to the losses, the acceleration will be higher with a person standing on the board. (at least before air friction takes over)
-
Btw, “Downhill runaway state where no electrical energy is applied to the system” isn’t even close to being likely… it would be very odd if the onewheel is able to balance itself going downhill, without any positive or negative electrical torque applied. Once you apply torque for just a short timestep, you are able to measure Momentum, i.e. if a person is standing on the board. Action → Reaction. A Vesc with FOC and HFI certainly can measure the momentum (total Mass) if balancing actions are taking place.
-
Indeed Vesc with FOC and HFI is a very reliable sensor of Electrical Power. When correlated with IMU data, you should “easily” be able to infer the Momentum.
-
The software implementation might even turn out to be simple, because any runaway state requires balancing actions - i.e. positive and/or negative torque applied. If NO balancing is required in a downhill runaway, it’s because a person is standing on the board doing the balancing. It can’t do it on its own.
-
I forgot off course that you would also need to know the Moment of Inertia of the wheel and motor. But this figure can be found by a simple automated calibration.