Is this a good time to mention the VESC was derived from instaspin? 
9 Likes
Always my friend!
Derivatives of derivatives of derivatives! How deep does this go?
3 Likes
As far as I am aware, we need only to maintain the use of TI processors to be in compliance with the instaspin tou’s.
3 Likes
Maybe it’s time for a purist TI-ESC. That’s gonna need a fancy name though.
3 Likes
TEX-ESC??? 
6 Likes
Hi @DerelictRobot, I just read your post here on the Forum. People have asked questions like: Is the Unity more a VESC 4 or VESC 6 based design.
VESC based design means it runs the Vedder code, since 98% of the work is in Software and not in Hardware. Benjamin can design a new ESC within a couple of days. The software takes years to code! Hardware wise you can create endless amounts of derivatives, just like smartphones running Android. Software might need to get more or less changes to run a hardware with changed components / Chipsets, but is not a big deal if you design your hardware wise enough.
If you open the Focbox UI, and click on the ABOUT button, you will see that the software is basically a fork of VESC TOOL, Copyright Benjamin Vedder. So yes, the UNITY is a VESC-based design! If it wasn’t, it wouldn’t need the Vedder Code, simple as that.
For Vedder, sharing knowledge is very important, since he himself learned a lot from open, shared code, and in consequence he also wants others to be able to learn from his code. Code should be visible and usable. Writing code, interacting with hardware, ultimately means the hardware needs to be understandable as well. There is a link…
At this stage UNITY is like a Computer that can only run a certain fork of Linux, due to a change in Chipsets. Such Computer don’t really exist for a reason. Maintaining an operating system fork for dedicated devices is even to much work for bigger players. Windows RT was binned soon after its introduction - to much work to maintain, to much extra work for App developers. Jeffrey now has a lot of work on his table because Benjamin coded a major update. Once Jeffrey nailed that he can start all over again, since the next big update will happen sooner than later. Sure, Unity is a bit cheaper to make because it saves 2,5$ on a second processor, but I guess that the workload to adopt the software all the time outweighs the cost savings big time.
VESC-Tool is progressing faster in future, and it will naturally support a wide range of different hardware configurations. It will always stay fully backward compatible. People want to be able to use new features, upload the latest and greatest FW, be sure to have bug fixes sorted reliably through the power of the many eyes principle and the main man behind the 20K+ pages of source code. A lot of people also have different controllers in different boards and bikes and robots. In the end they want one consistent software solution to deal with all of them.
Read more about it here: https://vesc-project.com/Ethos
9 Likes
Hear fricken hear.
Exactly my point in that these kind of things can be reverse engineered on the hardware side in very little time at all. And exactly why I think it’s strange that there’s so much emphasis on trying to keep the hardware design under wraps (especially given that it’s all derivative anyway).
Thank you for chiming in.
5 Likes
Exactly, If you know what you’re doing. I consider it the entrance exam if you want to make a clone/variant of the unity. I already did and released all the challenging parts making the FW support dual motors. If they aren’t even willing to put in a small amount of effort making a schematic, how good can we expect this new product they create to be?
In your super long post, I don’t really see any good motivations for why you need the schematic? We’ve had long discussions on the trade-offs here and I’d love to hear some other ideas on how releasing the schematics would help our customers. The main one I can think of is repair but we handle repairs pretty well as is and are more than happy to advise our customers if they want to go the DIY route.
@trampa what’s with the constant jabs in unity threads? I looked through vedder’s new update some really cool stuff in there if you want to use your vesc to drive subwoofers or chain a bunch together in a quadcopter. Also some improved calibration for motors that aren’t used in eskate. Really fun ideas and you can tell Vedder is super passionate about using the VESC in other platforms which is awesome. You keep quoting 20,000 lines of code though and how much better the vesc will work for eskate after the new update. But after looking through I draw the same conclusions as @Ackmaniac, the bulk of these updates doesn’t really do much for our application.
The main changes which apply to eskate are better support for dual/4wd setups over CAN-bus (Unity did this), improved flux-linkage detection (Unity did this), an automated motor detection routine to make things faster and easier (Unity did this), a braking fix for a bug that I found, as well as an app that has some baseline functionality but still has a long way to go regarding bugs/dropouts etc. He did all of these in different ways from my methods but the core ideas are the same. From the perspective of eskate, the VESC update was catching up to the ways the unity pushed forward, and not the other way around. We’ll continue pioneering forward and don’t need to spend too much time looking sideways as I’m passionate about the eskate application and want to create the best possible experience for our customers.
14 Likes
That’s great that you have your own opinions, I have mine.
In my opinion, it’s not up to you to determine whether or not to contribute to an open source project which you and your employer are financially benefiting from.
I thought I made it pretty clear that I don’t actually need the schematic personally.
What motivations do I need to convince you to do right right thing?
Are you not benefiting from derivative work and now trying justify why you should not have to contribute? It doesn’t work that way kid.
I’m not doing this entirely for myself, I’m doing this on good principle because not everyone has the skill set and experience backing their continued efforts towards learning that I do.
I am making this request because you are getting paid based on an enormous body of someone else’s work, and your employer has openly stated he doesn’t believe in Open Source and doesn’t care about it.
What you are doing is moving the goalposts and justifications for as to why you don’t think you should have to contribute back, and that is wrong. Furthermore you have a conflict of interest because you’re currently lining your pockets off a closed fork, for someone who doesn’t have any respect or understanding for the amount of work that goes into development like this.
If you don’t understand why this is immoral, I’m not sure what to tell you there champ.
This post comes across as defensive, and ultimately you have zero ground to stand on and your stance towards this would be torn apart within a larger open source community. Go float the question elsewhere and see the response, I encourage it.
If you do not believe you have a moral (and legal) obligation to pay it forward and give back to the community which you’re now making a living off of, then you have a lot to learn beyond the under-grad levels of Electrical Engineering it takes to design something like this.
Pretty disappointing response from you. I had hoped you came into this sport & community with a bit more open mind, and a bit less arrogance & possession over something you did a fractional amount of work on compared to those that came before you.
The idea that knowledge should be withheld is one of the very core tenets of malicious control.
11 Likes
The law says you must release the circuit schematics, the source code for the firmware, the source code for the GUI if derived from BLDC Tool or VESC Tool, but not the PCB gerber files or the design (aesthetics) files.
11 Likes
Correct. Watching this thread, now.
7 Likes
First off, can you try and remain polite and professional? Not sure why you feel the need to take such an aggressive tone, I can assure you it doesn’t further your goal. It is important that people don’t conflate the open-source requirements of the hardware vs. the software but I’d love to see a discussion of exactly how those apply here. For instance pretty much all vesc variants/flavours have changes within them and have no official schematics released as there is mostly just the reference schematic for the 4.12 and an old schematic of the vesc 6 before it was formally released, if this is an issue it is more widespread than an enertion and should be looked at in that context.
4 Likes
Sorry, willful ignorance & arrogance from someone profiting off someone else’s open source work tends to get me a little salty. I’ll use nicer words if they offend you, but I’m not a big fan of censorship and this is a topic I’m deeply passionate about. Ignorance is no excuse on your part.
You clearly don’t understand. And that’s fine. Maybe this topic will enlighten you.
There’s a difference between doing the bare minimum to meet ‘legal requirements’ and dragging your feet along the way, and doing something with the intent of contribution and free sharing of knowledge.
How long was Enertion in violation of the OS license? Did it not taken legal pressure from Vedder himself to get them to finally release the Source Code?
They didn’t do it out of good will or to benefit the community, they did it because they were finally left with no other choice.
Just how they’re willing to release the original FOXBOX schematic only now, after it’s no longer being sold. If you don’t see that as BS, I sincerely do not know what to tell you.
4 Likes
The focbox schematic has always been available actually, under the hardware reference files download from their website. I remember looking at like a year ago or more.
Then why could I only find v1.3/4?
And when I requested it from Enertion they sent me a 1.7 with the same date as the day I’d requested it on.
Wouldn’t it make more sense to point me to the existing link? (They didn’t, they generated a new file).
Why isn’t all of this just on your Enertion Github repo?
2 Likes
They could send you a letter with a paper version of the schematic… and still comply to the GPL licence.
The only thing that need to be share on a open source is the file you use and remix… If they didn’t use Vedder schematic they don’t need to make it open source… Look at Flipsky… Maytech… and other, they should be sharing there schematic since it is a remix from the original. Why aren’t you putting your effor them?
Let me guess… Because they aren’t Enertion… If you want the greater good of the community, you should also go after them.
But you just want to rub you dick in Jason face…
3 Likes
Who says I haven’t requested the same of them?
You should read up on this topic before making assumptions. I encourage it.
And please don’t place words in my mouth.
And please leave Jason’s and my own penis out of this.
7 Likes
Maybe it is you who should read more…
1 Like
How about this, guys.
@b264 is correct
@deodand could you, in good-faith, post links to the schematics, along with the source, and put this issue to rest?
To be clear: nobody here wants Enertion technology and we understand Enertion relies on Unity sales for income.
This isn’t an anti-Enertion thing; this is a pro-community thing.
@JohnnyMeduse is also correct, there’s no guarantee or SLA on this stuff. We just expect more as the community.
Can we keep those two things separate and focus on the resolution - and avoid further escalation?
12 Likes