EXTENDED ACKMANIAC-ESC Tool based on VESC-Tool

General Discussion
63

I heard i mentioned before… but it keeps just getting glossed over so i’m going to mention it again.

BLDC-Tool is is great. VESC is amazing. It was designed to be a motor controller for esk8s but it has turned into a motor controller for Every Goddamned Thing including Sumo Bots and Power Wheels races. Which is awesome.

But While BLDC Tool and the vanilla firmware is accommodating Every Goddamned Thing, Ackmaniac’s is trying to specifically accomodate esk8s with the needs we have right now specifically for esk8s.

Not to take anything from Ben or Trampa or anyone else working thier asses off on this, but that is precisely the kind of thing that causes forking and its not like we didn’t all see it coming.

12 Likes
64

Preach brotha, preach

4 Likes
65

As you may have noticed, the old Server has issues and needs to be replaced with a new one. That takes time…

Simultaneously there needs to be structure set up for the community to interact in a structured way. You need to consider that VESC-Tool is set up in a very structured way, so that changes can be made faster. The goal is to implement updates faster and allow developers to better understand the code base. In consequence code contributions can be implemented faster. This was done to allow more contributions, not to fork faster.

I talked to many people with code skills in person earlier this year and asked them to join in and work closer to the project or help out once the project is live. Instead of that we see the current situation, where Benjamin does tons of coding (two years of hard work) for the good of the community to see a forked version just months after the release.

In the end a day has 24 hours and code contributions need to be reviewed and changed to fit in perfectly. That is a process taking some time. The benefit is a better code base in the end and more compatibility, a consistent documentation and many more.

We are just 2 months away from the release! Priority A is improving the server, set up a structure for contributions and bang on hardware releases while adding in new features for the VESC-Tool simultaneously. Give it some time! Rome wasn’t build in a day. Now we face the situation that Benjamin will need to implement the features you are so desperate for, instead of finishing the public hardware release. It can’t be done all at once. But it will happen faster if more people are willing to contribute rather than shooting ahead with their own versions and ideas. In the end users want a version with all the features available they dream of. They want the hardware and code. But it all needs to fit together, code wise and time wise.

Imagine there is a completely new way to manage the power distribution, a lot more user specific and convenient to deal with. In consequence it would make sense to implement that over the modes that we know already. Unfortunately this would affect many sections in the app settings, like throttle curves, timout ramping etc. In consequence you bang on that new mode first and adapt the other settings later. A, B, C >> clean result

Such things can be implemented faster if everyone knows how to approach this, know A and B and C and skills are coordinated to achieve it. Currently Benjamin bangs on stuff like that and will implement it and Nico has to start all over again and adapt his fork to the new code and in consequence he has tons of work that he could have invested more efficiently if he worked on the original code base in the first place.

The current situation also makes it less likely that Benjamin will publish his coding schedule, since he would need to fear that forks will try to implement things faster to stitch him out. That is not good for the community and and collaborative approach we all envision.

OS-Projects live from collaboration and not from coexistence.

Frank

1 Like
66

(Are you sure I’m the target of your reply ?)

67

Sorry, no you are not, there is no target. I just want to explain how things are.

68

Im just gonna say this…In large projects, forks happen, there’s nothing you can do about it unless you move from open-source. It may not be palatable to you but its a fact of life. I would further suggest, this specific fork happened because the original project is not meeting the needs of a lot of people.

The VESC6 is too far reaching, trying to use the same hardware and software for multiple platforms is unlikely to be successful, there are many examples of this, 1 of which is the COMTEL LCD extravaganza of the early 2000’s. COMTEL bought 9 of the 12 manufacturing facilities in the world that made LCD’s. That left COMTEL and Samsung as the only manufacturers. COMTEL then reduced the form factors from hundreds of options to 5, the login being manufacturers will buy what we choose to sell. In the end Samsung made billions and COMTEL went bankrupt, because they kept making 100’s of different form factors.

This has been a constant for this project, specifically the VESC6. Seems like time management is the real problem you guys are having. Maybe focus on getting a reliable product to market, the worry about all the “moves-adds-changes”.

I totally disagree. I don’t think the VESC6 has been to terribly good for the community, at least I havent seen it make any huge advance in available options. I personally cant do anything with a VESC6 that I cant do with a FOCBox/TB Vesc. The @Ackmaniac firmware has definitely been a help to thousands of users.

3 Likes
69

Sorry i really don’t get it.

Is Benjamin or you Doubting that Nico does his work in a good way, or why are you not just thankful and happy that great work has been done by him. Probably it has something to do with “Coders-Pride” who did what first, and who did it cleaner. I don know how @Ackmaniac is looking at it. But Ben could just take Nicos changes, look over them change them if needed and add them to his “Vesc-Tool”.

And where is the Open-Source-Spirit if one Person in this case Ben or You? have to “bless” what other people want to have in addition.

1 Like
70

It must be terribly difficult trying to balance all of that out, and i can understand the frustration.

And at this point we’re dealing with a process similar to evolution, and the first most organized species out of the sludge may or may not be the survivor of that system. That also has to be frustrating, potentially infuriating. Like when a co-worker steals your spreadsheet and adds a few macros and makes the boss happy. The good news is that the work is done and everyone in the cubicle farm knows who did it. The bad news is that the boss doesn’t care who hands it in and has zero loyalty to anything other than his own immediate interest. In this situation, the overall esk8 community is the boss, and they don’t care who shows up with the best firmware or where it came from or who’s blood and sweat went into it.

Darwinian competition is ruthless and cold, but it is a very predictable animal. But you know all of this already.

6 Likes
71

I would say its best if everyone pulls on one side of the string for the good of the community and get things nailed in a structured way. The code base will be better on the long run and the spirit of OS is not Darwinian competition but collaboration. A group of coders all piss in one pot to combine their output to something with volume.

Frank

1 Like
72

Sounds Great in theory

7 Likes
73

Please, stop to argue with TM. Sounds like the Godwin point reached by the old uncle during a sunday family’s lunch… :smile:

1 Like
74

@trampa forking is good. Forking is amazing. Developers like it. A lot of open source projects have “Fork me on GitHub” ribbon on the website, this is a good thing! Truth is you can not submit a pull request without doing a fork first. Forking does not mean “not working together”.

@Ackmaniac whether you prefer to contribute upstream or not is totally up to you. I can understand if you were dissapointed by one of your pull request being rejected. This happens sometimes. Doesn’t mean it’s your fault. There can actually be other people who have time to take your code and create a pull request. Or this can be Benjamin himself. One thing that sucks though is that you did not want to share the code despite GPL license. It took multiple attempts and a rant from @Vanarian (thanks, man!) to make this happen, but the attitude is clear. We have been presented with a zip file. It’s like spit-in-the-face way of sharing (from the software engineer point of view). Technically this is OK, but doesn’t feel good.

My advice would be to put the code on GitHub, make a quick pull request and then walk away with clean hands. I wouldn’t stress to much if it gets accepted or not. Other people might be willing to tweak it and shape it until the point it gets in. And you will avoid ranting :wink:

Thank you for implementing new features, I am happy to see people excited about them! That’s the most important thing after all! :heart:

8 Likes
75

nah, thats what branches are for.

technicaly a fork a spearation of the original project which is agoing a different path. i do understand why they dont like forks, since forks make it pretty hard to be merged again in a later state.

however, if you have many contributors to a project, this usualy also requires a lot of work or “trust”. if its a open source project and you planed a specific way allready, then managing those can be rather chalanging.

i do get why they might be pissed about a fork, but if they dont have documented guidlines and the capacity to manage incoming pull request, then a fork is the natural way.

76

Sure you need to do a git branch to make pull request, but then the developer can see all changes and the difference in code with ease. The drop box folder we see has no .git folder which makes it hard to see all the changes that have been made. Anyone interested in sharing and enhancing the code should not set hurdles to others. Currently there is a “blanket” over the code changes that can only be lifted with a lot of additional effort. So that is what @rpasichnyk refers to when he says “spit-in-the-face”

Benjamin can implement stuff without the need of the source, but others might want to look what the difference in code is without the need to manually compare code pages.

Anyone interested in working on the VESC-Tool anf FW code should use github!

Frank

1 Like
77

@trampa

Have you guys thought about setting up a gerrit instance? Its a great way to include everyone in on code contribution.

78

I don’t like forks, this can get very messy and cause incompatibilities in the future but

Ben and Ack are heading in different directions, a great idealic VESC-Tool that doesn’t solve the problems of the esk8-people isn’t very helpfull and I see no way Ben is adding all the esk8-specific features in his software ever, this is not the way he wants to go. Even the VESC6 is overkill for esk8 imho, you can do about the same things with a smaller Focbox.

I think a good esk8-fork of the great VESC-do-everything-software(and hardware) is inevitable to get best results for the esk8-communty.

Everyone should Donate Ben and Ack :wink:

2 Likes
79

I will have a look at it . THX for the hint!. As soon as the new server is running tonight, I will ad a “VESC-Project” section to the forum to debate stuff like that.

Frank

80

How does one make a pull request ? Genuine noob question here.

@Pimousse @rpasichnyk thank you for your understanding guys. I’m less angry tonight, my head cooled down haha maybe a good time to compile those sources :wink:

@ackmaniac definitely produces quality work on this project and it must have taken lot of time. Apart from the time & discussion it takes to add a feature, I can understand why Ben might be uptight to add something totally different though.

I mean : it’s his baby. It is O-S and he’s been at it during his free time for few years now. Realize the sacrifice. Give him some space to breathe, he has his own schedule to make the project grow, specially since it went from “esk8” target to “everywhere”.

Anyway here is a proposition which should have been done already ?

  • Make an official pull request of the mods
  • Fork it too so current code is accessible while waiting for everything to be merged

Ben can easily follow development this way and we still get early access to the new working features while he focuses on his job.

1 Like
81

FOC works on Focbox with your firmware. TY @Ackmaniac

3 Likes
82

You’re welcome.

8 Likes