What do we consider stable? (VESC firmware, Community Fork Discussion, (SERIOUS)

Esk8 Dev
1

Hi Friends!

Your friendly neighborhood robot here- had some interesting conversations in recent weeks and was looking to get some input from the community.

Let’s call this a thought experiment:

Say that I was looking at the VESC project as an outsider, coming into it as a new developer that wanted to choose a firmware to designate for stable production in a VESC based derivative product. New peripheral features don’t matter, stable FOC operation and standard VESC features would be sufficient.

I ask this, because working in embedded systems, often at a certain point in the design process I have to choose a ‘stable/LTS’ kernel to build my distribution from, and commit to that as OTA updates on production devices are considered for critical security updates only. Often a kernel is chosen for its stability and support over its cutting edge features. I’d like to approach this question the same way.

The current release structure of the VESC project, in my opinion, leaves a lot to be desired.

  • There is no Stable/Dev release branch cycle for the VESC project. This creates a situation where untested code is released to the main code branch. This has been brought up repeatedly and disregarded so far.
  • We have an obfuscated or unclear QA/QC process when it comes to testing out new features and testing against code regressions. ie: How much testing did HFI get before it was released? How many riders? How many miles? Was there a feedback process with BV prior to release?
  • We have experienced a few instances (VESC 3.63/3.64, Unity also had 2 major code flaws in it’s first year) of code regression or critical bugs that impact rider safety, within the last 6 months even.
  • Lack of modern/sensible versioning/release control.

This project has a LARGE active userbase. There is really zero excuse as to why things continue forward in a flawed manner. Improvements have absolutely been made on Github in regards to accepting external PRs/responding to issues, etc. However insistence is that everyone should update immediately to the latest firmware/vesc tool, but that’s counter-intuitive to a lot of industries, and as someone that has been personally injured due to firmware bugs I lack trust in the more recent releases as the track record over the last year is not great.

Without a clearly defined developmental branch to test new code changes to, and a group of people that sign off on that after a specified period of time before its merged into a new branch, we will continue to have this completely avoidable risk at play.

This is the exact reason why ‘community stable’ forks such as Ackmaniac popped up and are still used & trusted to this day.

Personally, I don’t care about new features so much as I care about why we’ve had throttle runaway issues on recent firmware and how that could have been avoided in the first place.

So my question is, what firmware do you use & trust right now? I’m throwing in as many as I can think of that were semi-major releases, feel free to respond below if I’ve missed some.

(POLL DOWN BELOW SINCE DAMON KEEPS BREAKING SHIT)

Extra Credit Question: Would there be interest in a ‘Community Stable’ fork, potentially picking up where Ackmaniac/Nico left off and bringing things up to a more modern-yet-stable firmware and release fork & focused on stability/community driven app-side features?

Cheers loves!

49 Likes
2

Yes :smile: :+1:

25 Likes
3

Absolutely.

Can I also say that a GUI revamp would be incredible. The fact that you can’t TAB through fields drives me insane. I had a CS Professor that would straight slap the shit out of people for that.

20 Likes
4
  • 2.0+
  • 3.0+
  • 3.03 (Ackmaniac)
  • 3.38-3.40+
  • 3.58-3.60+
  • 3.62
  • 3.63 (don’t do that)
  • 3.64 (also don’t do that)
  • 3.65+
  • 4.0+
  • Unity (Older)
  • Unity (Current)

0 voters

Damon broke the first poll, so here it is again

4 Likes
5

Can you add an option to vote Yes please.

Tried to Read your text but gave up bu it trust you guys know what you are doing.

4 Likes
6

Yeah, this is a bigger part of it. I feel like having a bit more interaction with the community for user-experience feedback would be beneficial and that’s not really something BV appears to have time to do (don’t blame him either, we’re a whiny bunch). But as it’s been said many times, nothing stops us from simply taking it into our own hands and making the changes we want to see made. Just would require a community effort.

5 Likes
7

I haven’t coded anything other than Python and PHP in years, so not sure how much help I would be, but let me know if I can.

3 Likes
8

I don’t have a VESC or VESC derivative, but I watch how this project is maintained for a while now and I can’t help but consider it unprofessional, at best.
If I would ever get a VESC I would love to have a firmware fork that is maintained in a more appropriate way and focuses on stability and safety.

7 Likes
9

My ethos so far when updating is don’t mess with it if it’s not broken, I think I’m still on 3.38 or something like that, for the same reasons you share

As far as when to base, any release that has been used for a while and we have no news of issue should be ok as a base

3 Likes
10

That’s been my logic so far – if the latest release is 1-2 weeks old, then it’s probably safe.

Btw, didn’t Vedder recently implement a warning in vesc tool, that checks if your current firmware has any known bugs and you should update? That must mean there’s a black-list of unsafe firmware versions, meaning the rest are probably safe :laughing:

1 Like
11

The current release system, as it stands, resulted in 2 potentially dangerous/unstable firmware releases back to back. Unity codebase stands in a similar spot only having a single developer maintaining it for most of it’s life. Please don’t take these as condemnations of the developers behind these projects, rather a practical look at how we can better improve safety by establishing stable, staged releases.

As it stands, I don’t personally have confidence in the current release system without changes being made to stage Dev vs Stable, with a feedback cycle for Stable releases. I think we can help improve that as a community.

13 Likes
12

The problem is, the firmware is not agonistic to the power stage, meaning using better MOSFETs ends up screwing things up on certain settings, which change depending on the firmware version.

As an example, firmware version 4.xx with SAMPLE V0 V7 does not work on the flipsky 6.6

Most firmware versions will work with a certain vendor’s hardware if you screw around and find compatible settings.

3 Likes
13

I have one skate running Trampa 4.1 (I’m not calling it Vedder because he’s NEVER present in ANY discussion EVER and does whatever the fuck he wants) as an experiment (where a bug or glitch could possibly kill me…) SOLELY for the HFI feature.

Every other skate has Ackmaniac 3.103 or 2.54 because I trust them and know I’m not going to get thrown off my skate while carrying my dog in traffic downtown.

10 Likes
14

So what is your proposed solution to this?

4 Likes
15

Compile a list of known vendor variants and their compatible firmware versions and settings.

I’ll dig through my flipsky escs and try to get data on those.

4 Likes
16

Huh. I thought I was the only one who found that strange.

Always feels like we are the beta testers every release.

12 Likes
17

That’s because we are xD.

10 Likes
18

This seems to be how big new releases are tested :thinking:

I quote: “I will tweak the code a few more days and then push everything to github. There are thousands of new and changed lines to support all the old functionality as well, so there can be regressions, which is why I have to test and tweak it.”

If Ben was able to successfully go forwards and backwards 2-3 times at 2mph it is probably safe to push to the master :+1:

18 Likes
19

Great thread and I agree with everything said so far.

Imo with a project of this size that is this safety critical there is no reason not to have a Dev branch, or at the least more regular beta firmwares that can be installed by hardcore DIY guys for testing but aren’t seen by default in the app. When tested enough this release comes out of beta.

To do this literally all that would have to change is a better firmware numbering system, good change log with each release and a tickbox in the app to show non stable releases (at your own risk).

Seems like a simple decision to make the update process way safer.

15 Likes
20

Not only is it a fairly minimal effort, it’s an industry wide best practice, even in devices where human safety isn’t at risk. It IS at risk here, which is all the more reason why we should be taking every precaution.

17 Likes