To me, a software run-away detection looks more and more like a “stupid” simple KALMAN filter… with a few laws of physics built into it…
You keep two filters going:
Filter 1: Filters data as if a person is standing on the board
Filter 2: Filters data as if a run-away state
Then you observe which one has the smallest/largest error. Damn, it’s simple.
I have no doubt that you can detect run-away reliably. The question is: How fast can you detect such a state? How many data points are required for the certainty in the detection to go above a 99.9% threshold?
You’re talking about current limits, I’ll add them to Refloat as well, most likely in the next version.
About the KP 2 feeling like 1.5 I don’t think so, it’s still the same (both code-wise and how it feels to me). But by using lower Roll KP you stiffen up the nose noticeably so maybe that’s what you’re observing…
Put in new battery couple days ago and thought something was off with what I did but then disabled refloat loaddd float and it worked fine tried it again just now and instantly got hard pushback like out of battery pushback . Reinstalled float then put re back thinking it as in my head and nope it’s jacked up not sure why
Refloat is now available in the VESC Tool Package Store.
The Info text is messed up (I know, Float has it semi-working), not much I can do about it now. It’ll be fixed in the VESC 6.05 release, which is scheduled to happen soon. In the meantime, you can find the same text here: refloat/package_README.md at main · lukash/refloat · GitHub
I recently updated to refloat, and overall the feel is great but after review of the notes and differences in tuning. My question for us clydesdales is that the board is acting very loose even with the kp and rate p and angle p adjustments matxhing to what i had in float package. Could you provide a couple insights to get a more reactive board with some tuning? I attached my tuning metrics i utilized before and would love to get a bit stiffer feel and welcome the inisghts to do that!!
If you set your Roll KP to the same value as Pitch KP, it should ride the same as Float. But lower Roll KP should make the board a bit stiffer, not looser. So I suspect you have some difference in your config or something. Otherwise I don’t know why it would be looser with Refloat.
Brother that did the trick THANK YOU!!, i also added a smidge of torque tiltback and man Refloat rides soooo smooth over tabletops and the double KP gives mission front to back axis playfulness but when you step on it she GOES!! For context im 240ish and on 19s2p SF HT.
Btw, any reason you included Accelerometer Confidence Decay as a configurable parameter? I mean, I know why, but is there justifiable reason for having it be configurable, vs. hard coding at the same 0.02 that has been the standard for the past few years?
My main concern is it being front and center on the main Tune tab more than anything, that seems like a more volatile one for someone who doesn’t know better to start messing with trying to figure out what it does and how it changes the tune (when it should really just be left alone for 99.9% of people).
I don’t think it would be a big deal to just have it be hard coded and out of the way to mitigate risk for the user experience (I think it’s probably doing more harm than good being mixed in like that). Or at the least, it probably makes the most sense to move it over into the Specs tab so it’s out of the way and people don’t confuse it for being a parameter that people typically tweak when tuning.
I have no specific reason for it besides it being configurable in Float and I didn’t really know if it’s important or making a difference for someone. It’d help me if you summed up what you know about the Accelerometer Confidence Decay, as I haven’t really read or participated in any discussions and only have my observations (of some non-conclusive experiments when I tried messing with it). But this is not meant to be a development discussion thread so lets perhaps do it elsewhere.
TLDR; I’m not opposed to moving it or hardcoding it.
So there’s definitely an issues migrating the thor300 from float to refloat for LED lights and indicators.
Need to setup in refloat > Specs > LEDs :
LED type: RGB
LED Pin: Dedicated Pin
LED Color Order: GRB
That helped me get the head lights and tail lights working. Although I’m still not sure what the difference in the multiple headlight and taillight settings are. Static tab doesnt seem to do much.
Issues: Thor300 controller lights no longer turn on (indicator light to show it’s powered on and indicators for ADC activity)
No longer getting battery’s % indicator on the front LEDs when idle.
Not sure if someone here has had luck with their configuration on the Fungineers Thor300 set up?
Thanks all, Refloat is indeed a great ride especially dealing with quick transitions.
The only thing I found needs to be changed on a fresh Refloat Thor install is the LED Type: RGB, the rest of the default values work.
If your status bar is not working, post your config. You can also check the rest of the options and read the descriptions if you don’t understand what they do. If, after reading the descriptions, you still don’t understand, you can also bring it up and the description can be improved.
No longer getting battery’s % indicator on the front LEDs when idle.
Refloat doesn’t do this, it was a Float feature. You have the battery on the status bar and you can have it on the front bar when you lift the board (stand it up) if you configure it so.
Just wanted to know if adding I2C to the Leds has been done by anyone? I suppose more specifically has anyone achieved using the I2C_BB driver from the vesc c interface? I wrote libraries for a pca9685 chip to control leds long before anyone had a solution for leds but I did everything in lisp because Ben had the I2C functionality already in lisp but now I would like to move to c so interfacing with float/refloat is a lil more seamless. Just need I2C from inside the c interface.
