jtm94 Posted September 23, 2022 Share Posted September 23, 2022 So I had a few questions regarding the control PIDs of Begode wheels. Is it possible or are we at the point where we can modify the stock PID loops to change ride feel? I would be interesting in changing the behavior of pedals during turns to reduce dipping for example. The main reason I ask this is I was curious if we could copy control algorithms from other related wheels like putting RS HS feeling firmwares onto an EXN HS. As a light rider I feel the EXN is unnecessarily unresponsive and requires extreme force or leaning to do what used to be simple. All that aside I'd like to try out the 75% PWM tiltback on my EXN HS. I have the most recent EXN C30 firmware, do you have that firmware with working PWM tiltback? Also curious if you could disable the beeping once the wheel goes below 79 volts, I can run it down to 72 volts tested, but the wheel constantly beeps the entire time and I have to turn my beep volume down. 2 Quote Link to comment Share on other sites More sharing options...
Popular Post Freestyler Posted September 23, 2022 Author Popular Post Share Posted September 23, 2022 (edited) About the low voltage alarm: I can remove the beep, but the best solution here would be to just lower the gap between the alarm & final tiltback. That's what I do already in the low voltage mod I offer. Something like 74v - 75v for the low voltage alarm. It's a sensible option to set the volume to 1 as to not being annoying. The PWM alarm will sound at the maximum volume anyway, so no need to worry. I have ported the firmware to the latest exn c30 firmware, yes. About the PID: I have found them, but have not fiddled with them yet. Here are the PID values for the EXN for example: Quote # Hard p = 14 i = 55 d = 500 # Medium p = 7 i = 50 d = 450 # Soft p = 5 i = 45 d = 450 How do I know that these are PID values? You can see in that VESC video values that correlate very closely with what I found. New wheel firmwares usually have an oscillating bug on medium / soft (they don't seem to test these modes much) and are usually resolved with a small tweak of D. I have thought about adding more pedal modes or offer infinite adjustment (not all the combinations will work), but this needs a lot of time. The pedal dip in turns or consecutive bumps is a more complex problem and not just a matter of PID values. It's a combination of things like the accelerometer, ahrs bias, attitude, roll and other stuff that are way over my head at this point. Edited September 23, 2022 by Freestyler 6 1 Quote Link to comment Share on other sites More sharing options...
jtm94 Posted September 24, 2022 Share Posted September 24, 2022 I am extremely interested in what the values of an RS C30 are compared to an EXN C30, this is really interesting information. Quote Link to comment Share on other sites More sharing options...
supercurio Posted September 24, 2022 Share Posted September 24, 2022 Super cool once again @Freestyler! The ability to set the PID values between more presets identified as safe and effective for a wheel would be another game changing feature. 1 1 Quote Link to comment Share on other sites More sharing options...
Popular Post Timwheel Posted September 24, 2022 Popular Post Share Posted September 24, 2022 (edited) Reminds me of my old lessons.... The fact that the D is higher in hard mode explains the feeling that the pedals are fighting back when accelerating. To paint a very gross picture, the D can be understood as "anticipating", I "correcting" and the P is more like instant response. For example, a PID from soft : p = 5 i = 45 d = 450 Would autocorrect itself after the initial acceleration with a higher I value. The low P value makes the initial response "soft" and lower D makes the wheel "accept" that initial pedal tilt. Playing with those can be fun. I'd like a mode with low P for a fast initial tilt to help accelerate but high I so that once cruising the pedals come back up faster. Edited September 24, 2022 by Timwheel 1 3 Quote Link to comment Share on other sites More sharing options...
supercurio Posted September 24, 2022 Share Posted September 24, 2022 (edited) @Timwheel the mode you're describing is what I found missing on most Begode wheels I've tried. Some amount of give for comfort and to help quick reactions without relying too much on pads, and going back near flat quickly but without bouncing/oscillations as sometimes experienced. Something you can find on Inmotion and Kingsong wheels. I found this behavior only on one specific, older EX.N firmware is medium mode when trying a friend's wheel. Edited September 24, 2022 by supercurio Quote Link to comment Share on other sites More sharing options...
Popular Post Freestyler Posted September 25, 2022 Author Popular Post Share Posted September 25, 2022 23 hours ago, supercurio said: Super cool once again @Freestyler! The ability to set the PID values between more presets identified as safe and effective for a wheel would be another game changing feature. Yeap. Having some known presets from different firmware versions or very similar wheels is a more realistic approach. Infinite adjustment would be @houseofjobdream feature though. 2 2 Quote Link to comment Share on other sites More sharing options...
PCK Posted September 25, 2022 Share Posted September 25, 2022 Very good job. Thanx a lot. I will PM you too. (and sorry for this useless post, first one, you know why...) 1 1 Quote Link to comment Share on other sites More sharing options...
Antoni Chujek Posted October 5, 2022 Share Posted October 5, 2022 @Freestyler Can you help me change the firmware for begode ex.n? Unfortunately I updated the firmware to the latest one and it was a mistake. It is impossible to drive on the wheel, the wheel has no power, it wobbles it on bumps. I would like to go back to the firmware accelerated stability, unfortunately it is no longer available in the begode app and the manufacturer ignores me. https://youtube.com/shorts/WSQn925jCzE?feature=share https://youtube.com/shorts/IuxMQg276bU?feature=share https://youtube.com/shorts/uxFqTMS5n4c?feature=share Translated with www.DeepL.com/Translator (free version) 1 Quote Link to comment Share on other sites More sharing options...
Vanyayak Posted October 6, 2022 Share Posted October 6, 2022 On 10/5/2022 at 12:44 PM, Antoni Chujek said: @Freestyler It is impossible to drive on the wheel, the wheel has no power, it wobbles it on bumps. why is that so? you updated on mten firmware?)) maybe u need to re-calibrate? Quote Link to comment Share on other sites More sharing options...
Mike Lee Posted October 11, 2022 Share Posted October 11, 2022 hey @Freestyler would it be possible to get the exn ht (c38) accelerated stability firmware on the mix? 3 Quote Link to comment Share on other sites More sharing options...
Popular Post Freestyler Posted October 18, 2022 Author Popular Post Share Posted October 18, 2022 (edited) Another huge update! I managed to bring the PWM into the main packets. I have only been able to do it thus far by replacing the temperature value. This is bad for 2 reasons: 1) Temperature is a useful value to lose 2) DC boards (responsible for lights, screen etc) are just clients connected directly to the main board via serial protocol that read the packets like apps do. (it has the same mcu as the main board and runs its own firmware) By replacing the temperature, dc board reads an incorrect value and cannot react to it (start the fan) This time I managed to replace a useless value that no app or even the dc board reads. That's the number of motor initializations (called "resets" in euc dash). Each time you put the wheel on it's side the motor is disengaged. When you put it back up this number is incremented. Quite a useless value indeed. So this means that we have a fast update like the rest of the values (speed, current etc) without sacrificing anything useful. It would be cool if other apps support it as well, although I realize that quite a few people run a custom firmware (around 50). So far it's implemented into my own MCM5 wheel, but I will slowly port it to all other wheels! Video showcasing the PWM (set on 70%): https://streamable.com/cs1xt8 Edited October 18, 2022 by Freestyler 7 7 Quote Link to comment Share on other sites More sharing options...
jtm94 Posted October 18, 2022 Share Posted October 18, 2022 Yes! I've been waiting for this for so long. So if we are already running your firmware we will still need to update to this new one correct? My main thing is I want this to be read on my watch with the flashed euc watch firmware on it. I wonder how we can make that happen. @enaon Would be useful to have on the main screen with my speed, maybe we could toggle time with the value this PWM% replaces? 1 Quote Link to comment Share on other sites More sharing options...
enaon Posted October 19, 2022 Share Posted October 19, 2022 (edited) 1 hour ago, jtm94 said: Yes! I've been waiting for this for so long. there is pwm bar on the dash already for kingsongs, and pwm based haptic, I will enable them for gotway too now that Bill made progress, I will inform on the telegram group. Edited October 19, 2022 by enaon 1 2 Quote Link to comment Share on other sites More sharing options...
Popular Post RolluS Posted October 22, 2022 Popular Post Share Posted October 22, 2022 On 10/18/2022 at 9:19 PM, Freestyler said: Another huge update! I managed to bring the PWM into the main packets. This is dope. @Seba This would optionaly replace the safety margin calculated by EUC World probably? Also I would love to have that on the dashboard, maybe in replacement of the current or speed gauge.@Freestyler maybe you could flag the custom firmware, like, assuming its an unsigned integer, adding a mask to LED Mode or something like that, so other apps knows there is a pwm value available On 10/18/2022 at 9:19 PM, Freestyler said: Each time you put the wheel on it's side the motor is disengaged. When you put it back up this number is incremented. Quite a useless value indeed. that is the crash counter On 10/18/2022 at 9:19 PM, Freestyler said: So this means that we have a fast update like the rest of the values (speed, current etc) without sacrificing anything useful. It would be cool if other apps support it as well, although I realize that quite a few people run a custom firmware (around 50). See above, that would be awesome. I've tried your firmware this afternoon, with a 50% PWM threshold. EUC.World safety margin calculation was not far (plus I'm using @supercurio's EUC Alarm), but sensing the tiltback is priceless for safety. On 10/18/2022 at 9:19 PM, Freestyler said: So far it's implemented into my own MCM5 wheel, but I will slowly port it to all other wheels! Video showcasing the PWM (set on 70%): https://streamable.com/cs1xt8 I confirm it works on my T4 as well. (I guess you already know ) Is darknessbot already compatible? PWM was stuck to 0 before I reflash. I'm using EUC World and just installed Darkness Bot from google playstore.https://streamable.com/dplamo 5 Quote Link to comment Share on other sites More sharing options...
supercurio Posted October 22, 2022 Share Posted October 22, 2022 Rollus, I'm interested by an EUC Alarm app recording of these packets by the way Quote Link to comment Share on other sites More sharing options...
RolluS Posted October 22, 2022 Share Posted October 22, 2022 21 minutes ago, supercurio said: Rollus, I'm interested by an EUC Alarm app recording of these packets by the way OK, I'll do this on Monday, I'm not gonna ride tomorrow as I am going to Salon de l'Automobile in Paris (a big static car show with new models, technology, etc...). Are there specific situation you'd like me to do or just riding around? Your proxy has been very usefull for these test BTW. Begode app, Darkness Bot, and EUC Dash are struggling to connect when they are not the first to connect, but I do not use them regularly so I don't mind. 1 Quote Link to comment Share on other sites More sharing options...
Freestyler Posted October 23, 2022 Author Share Posted October 23, 2022 15 hours ago, RolluS said: @Freestyler maybe you could flag the custom firmware, like, assuming its an unsigned integer, adding a mask to LED Mode or something like that, so other apps knows there is a pwm value available There is already something in-place to identify the custom firmware. The speed alert setting would be 3 for anyone that enabled the PWM tiltback (which is the main reason to run my custom firmware). You can set it on a stock firmware and it will behave almost like mode 2 (almost, because it sets some alternative PWM limits) and that can only be done through euc-dash. Additionally until I port it to all firmwares, some wheels will not show the PWM despite having speed alert 3. All wheels will slowly get it though, so I don't think we need to worry of the above edge cases. TLDR: If speed alert is 3, read PWM from packets. 15 hours ago, RolluS said: @Seba This would optionaly replace the safety margin calculated by EUC World probably? Also I would love to have that on the dashboard, maybe in replacement of the current or speed gauge. Is darknessbot already compatible? PWM was stuck to 0 before I reflash. I'm using EUC World and just installed Darkness Bot from google playstore.https://streamable.com/dplamo No 3rd party app has implemented it yet afaik. 2 1 Quote Link to comment Share on other sites More sharing options...
Popular Post Seba Posted October 23, 2022 Popular Post Share Posted October 23, 2022 6 hours ago, Freestyler said: No 3rd party app has implemented it yet afaik. In next few days I plan to release 2.22.1 minor update and it's a great opportunity to add support for your custom firmware in EUC World. But it would be great to have something that could be used to distinguish between stock and your custom firmware. Relying on a speed alarm mode isn't the best idea, though. I concur to @RolluS that having something in the data packet that is specific to your custom firmware would be great. First, this would allow to set alarm mode to 3, second, it would allow to use PWM reported by the firmware as safety margin instead on relying on calculated safety margin. 4 3 Quote Link to comment Share on other sites More sharing options...
RolluS Posted October 23, 2022 Share Posted October 23, 2022 7 hours ago, Freestyler said: There is already something in-place to identify the custom firmware. The speed alert setting would be 3 for anyone that enabled the PWM tiltback (which is the main reason to run my custom firmware). TLDR: If speed alert is 3, read PWM from packets. No 3rd party app has implemented it yet afaik. OK thank you for the clarification @Freestyler 55 minutes ago, Seba said: In next few days I plan to release 2.22.1 minor update and it's a great opportunity to add support for your custom firmware in EUC World. But it would be great to have something that could be used to distinguish between stock and your custom firmware. Relying on a speed alarm mode isn't the best idea, though. I concur to @RolluS that having something in the data packet that is specific to your custom firmware would be great. First, this would allow to set alarm mode to 3, second, it would allow to use PWM reported by the firmware as safety margin instead on relying on calculated safety margin. @SebaMaybe a user input would be also a good option. Just after the "reverse power/current" option, adding "custom firmware with PWM report". I would love to see PWM displayed on main screen. On the same topic, I wrote a tip here about law enforcement setting mode to less or equal to 2 if using custom firmware: 1 Quote Link to comment Share on other sites More sharing options...
Freestyler Posted October 23, 2022 Author Share Posted October 23, 2022 5 hours ago, Seba said: In next few days I plan to release 2.22.1 minor update and it's a great opportunity to add support for your custom firmware in EUC World. But it would be great to have something that could be used to distinguish between stock and your custom firmware. Relying on a speed alarm mode isn't the best idea, though. I concur to @RolluS that having something in the data packet that is specific to your custom firmware would be great. First, this would allow to set alarm mode to 3, second, it would allow to use PWM reported by the firmware as safety margin instead on relying on calculated safety margin. That's exciting! I have forgot that setting the PWM tiltback from other apps should also be an option, so you are correct that relying on speed alert is not good enough. I have to think something else. One idea would be to alter the firmware version slightly. Example of a firmware version: GW1401001 The first 4 digits signify the model (GW1401001 is mcm5). Thse digits are also checked by the firmware in the dc board to distinguish between models and choose the appropriate behavior. The 5th digit is usually an incompatible version (GW1401001). For example Master & T4 change this number between revisions. The last 2 digits are reserved for the version within that wheel (GW1401001). Version 1 in this example. Changing any value other than the version will lead to a mismatch and flash rejection. I'm not sure what happens if you change the GW1401001 label at the start. (it could be changed to Custom Firmware CF1401001 or something similar) The app seems to drop the first 2 characters, but I don't know if will be accepted when flashing. All in all it doesn't seem like a good idea to change the firmware version. Another idea is altering the wheel model. Example: NAME:MCM5\r\n I can't increase the size, because that's too much work. I can alter existing characters. Can't change the NAME:MCM5\r\n part because begode app specifically searches for it and drops it. We could change that carriage return character NAME:MCM5\r\n to something else like NAME:MCM5!\n I'm open to other ideas! 2 Quote Link to comment Share on other sites More sharing options...
supercurio Posted October 23, 2022 Share Posted October 23, 2022 @Freestyler: no objection to using the Bluetooth name to denote a custom firmware version. Do you anticipate the need for versioning of the protocol? 1 Quote Link to comment Share on other sites More sharing options...
Popular Post supercurio Posted October 24, 2022 Popular Post Share Posted October 24, 2022 (edited) @Freestyler While writing about battery safety, I just thought it would be really useful to build robust alarms to have: phase current limit on the current firmware: static battery current: dynamic A more robust alarm model will alert on at least these 3 thresholds: % of PWM % of phase current % of battery current vs battery spec That way we have a method to avoid slow speed overlean when running out of phase current for torque, PWM for obvious reasons and battery current to avoid damaging cells on strong accelerations or hard braking. I remember that the battery current value is measured and sent in the extended packets, so I guess the value is somewhere in memory and could be sent if there's some free space available 😆 (maybe mixed in the new 16-bit PWM field) Phase current limit is hardcoded so it could be put in the BT name too. What do you think? Edited October 24, 2022 by supercurio 1 3 Quote Link to comment Share on other sites More sharing options...
Popular Post Seba Posted October 26, 2022 Popular Post Share Posted October 26, 2022 (edited) On 10/18/2022 at 9:19 PM, Freestyler said: It would be cool if other apps support it as well, although I realize that quite a few people run a custom firmware (around 50). I think that adding support for your custom firmware to EUC World would make it much more popular. This is clearly a huge advance in regard to stock firmware, especially in terms of safety. I have a two ideas: 1) I think that using UINT16 for PWM is a waste of precious data frame space What about sending PWM as a UINT8 in lower byte, so we can have another byte for something else? For example, you can set 8th (most significant) of upper byte and this could be used to distinguish between stock firmware and your firmware. Why? Because setting this bit and assuming it a 16-bit value, we'll get negative value for INT16 or value of 32768 or more for UINT16. Both are unlikely to receive for "motor initializations/resets" value sent by stock firmware. So seeing this bit set we can safely assume that we're running your custom firmware 2) When using UINT8, we still have 8th (most significant) bit unused and avasilable for some kind of flag. After all, we dont need values over 100 %. On 10/24/2022 at 2:52 PM, supercurio said: I remember that the battery current value is measured and sent in the extended packets, so I guess the value is somewhere in memory and could be sent if there's some free space available It would be great discovery, but are you sure? When I examined Begode motherboards, I didn't noticed any kind of shunt or current sensor other than shunt resistors on two motor phases. Edited October 26, 2022 by Seba 4 Quote Link to comment Share on other sites More sharing options...
Popular Post supercurio Posted October 26, 2022 Popular Post Share Posted October 26, 2022 (edited) 19 minutes ago, Seba said: I think that adding support for your custom firmware to EUC World would make it much more popular. This is clearly a huge advance in regard to stock firmware, especially in terms of safety. I have a two ideas: 1) I think that using UINT16 for PWM is a waste of precious data frame space What about sending PWM as a UINT8, so we can have another byte for something else? For example, you can set 8th (most significant) of MSB and this could be used to distinguish between stock firmware and your firmware. Why? Because setting this bit and assuming it a 16-bit value, we'll get negative value for INT16 or value of 32768 or more for UINT16. Both are unlikely to receive for "motor initializations/resets" value sent by stock firmware. So seeing this bit set we can safely assume that we're running your custom firmware 2) When using UINT8, we still have 8th (most significant) bit unused and avasilable for some kind of flag. After all, we dont need values over 100 %. Maybe 8 bit precision for PWM with max PWM supported by the controller being the value 255. Can it reach above 100%? (you never know...) And 8 bit signed precision as well for battery current. What would be a reasonable yet future proof value. Maybe around 100A as maximum, -50A minimum. Then 8+8 uses the 16 bits available 😁 Although if there's enough space available elsewhere in the protocol that's not used by a daughter board or display, maybe having each value occupying an uint16 or int16 would be plenty fine. 19 minutes ago, Seba said: It would be great discovery, but are you sure? When I examined Begode motherboards, I didn't noticed any kind of shunt or current sensor other than shunt resistors on two motor phases. Yes @Freestyler found battery current to be reported as a maximum, named RoatCurrMax Reference: EUC Dash launch post Edited October 26, 2022 by supercurio 4 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.