FOCBOX Unity & Enertion's Responsibility To Contribute to OS

Hello all,

Recently I contacted Enertion support asking about the availability of the FOCBOX & FOCBOX Unity technical hardware schematics. I have purchased both controllers either directly from Enertion or through a licensed distributor.

I had looked to see if the latest version of the FOCBOX hardware schematics had been published on Enertion’s GitHub account or on the forums but the latest I could find was v1.3.

I emailed Enertion support asking for these directly, and was told to two things.

  1. That they had already released the latest FOCBOX hardware schematics on the forums. They provided these in their email response, but I couldn’t help but notice the date on the Schematics was the same day of my request. Not sure on that, but I appreciate them providing them so I will refrain from further comment.

  2. I was told that the FOCBOX Unity was not a VESC derivative and therefore they would not be releasing the hardware schematics open source.

The exact response from Bara was:

“The Unity hardware will not be released as it is not based on the Vesc.”

Topic 2 is what I would like to have a discussion on. I specifically asked for only the schematics, not the design files, as that aligns with the example that Vedder set with the lastest VESC6 release. For an embedded systems engineer such as myself, this is all I need to be able to contribute.

Now I feel it’s pretty safe to say the original FOCBOX is clearly a derivative of VESC. I also feel it’s safe to say that the FOCBOX Unity is a derivative design based on the original FOCBOX and by association, also a VESC derivative.

I’m not going to talk about legality here. I’m going to talk about what I personally feel is right, based on the tenets of open source philosophy. The goal of these open licenses is to encourage innovation and collaboration from the community involved with the project, not to fork & isolate hardware so that it is no longer part of the original open source project.

Given my experience in embedded systems as well as my contributions to the open source robotics community over the last decade, the claim that the FOCBOX Unity is not a VESC derivative comes across as inaccurate and potentially misleading, and I fear there’s a clear conflict of interest here.

@onloop I ask that you weigh in on this.

You have benefitted monetarily on the open source work published by Mr. Vedder. I feel it is against the spirit of the open source work in which you have directly benefitted from to create a closed fork and not contribute your improvements.

If you claim that the FOCBOX Unity is not a derivative of the FOCBOX, which is clearly a VESC derivative: I would be more than happy to volunteer my skillset to shedding some more light on this claim as I have a Unity in my possession and creating an empirical and quantifiable comparison to look further into this is well within my reach. It’s about a weekend at most of my time, which I’d gladly donate to support the open source VESC project.

Thanks for taking the time to read. I hope my intentions here are clearly understood.


Thanks for your insight & feedback, I’m happy to try and answer your questions if you have any.

In the meantime please refer to Benjamin Vedders comments about hardware:

In the future we will publish the schematics for all official VESC hardware, but not necessarily the complete hardware layout with gerber files. The reason is that unlike the software, the hardware layout is not very reusable when creating new hardware. For example, for creating the VESC6 I made a completely new project in KiCad and only looked at the schematic for HW4.12 to get started. Likewise, when working on a new high power layout that even looks similar to the VESC6 with the L-shape but with 18 MOSTEFs, I created a new project from the start. Once you know how to make a proper high power layout and are familiar with the awesome KiCad, it is just faster and simpler to layout everything from the start rather than moving things around. Therefore the software, tutorials and schematics are enough as a great base for making a wide variety of awesome motor controllers. Over 99% of the work is in the software, and the software can be adapted and reused to a great extent, which is why we think the right thing is to keep it free and open source.

Another reason for not publishing the official hardware layouts as-is, is that it leads to many companies and individuals who have no background in electronics just giving a github reference to a manufacturer to make hardware and start selling it. Currently there are more than 25 places where V4.x hardware can be bought, with quality varying from excellent to not working at all. If the same thing would happen with the VESC6 it would be confusing for the customers. If you are serious about electronics, the VESC project provides everything you need to make your own custom hardware to fill a missing spot in the market, and then sell it. If electronics is not your area, but you want to sell your own hardware independently anyway, you can refer to the HW4.12 layout or wait for the three shunt reference PCB. We do however recommend and encourage that you get into electronics and design your own hardware if you are serious about what you are doing.

read more here:


I don’t think he’s asking about the gerber files. I’m pretty sure he means the schematics.


That’s correct. I specified I am not looking for the hardware layout. Only Schematics.

I was deliberate in this distinction. I completely understand Vedder’s view on this and agree entirely.


We may release the schematic in the future. It’s definitely something that has been discussed internally and we may need to revisit this if we are unknowingly in breach of some license or law.

We are not experts on the law regarding this matter, so feedback from the community is appreciated.


I also specified I’m not talking about the legality of this matter @onloop

I’m talking about the responsibility of contribution and doing what is right. I took time to write what I feel was a thoughtful post. Please take the time to read it, both of your responses so far show me you have not.

If you do not understand what I’m asking, I’m more than willing to expand.


I read it, thanks for taking the time to put your thoughts down.

I don’t have much more to offer at the moment.

1 Like

@onloop Could you respond to this then?

That was directly from Enertion support.

The claim is that the Unity is not a VESC derivative. My experience designing these kind of controllers for more than a decade leads me to believe that is not an accurate statement.


We are able to read a datasheet by ourselves and did not use the vesc4 nor vesc6 schematic


I am not an Electronics Engineer, Nor am I the person who designed the Focbox unity, so I could be technically wrong and I am happy to be corrected.

What I do know is that the Unity is similar in the sense that it has similar components that are commonly used in vesc based motor controllers, it also uses similar code to make the components function as intended.

In saying this it is also unique, because it has new components and new code to make it function slightly differently.

Sorry for the layman’s terms


I could have sworn the Unity webpage used to say “Based on VESC™ Open Source Project.” I’m not sure how to verify my claim. If this is true it is evidence that internal debate is occurring and actions are being taken. If I am mistaken I will remove this to avoid confusion.

I’ve read through threads on the OS debate between Enertion and the community and while it’s not my expertise (and frankly not my concern) I hope that the Unity can do more than unify two motor controllers.


I can do a bit more detailed comparison between the Unity and the FOCBOX when I land back stateside.

Just as you are able to read datasheets, I don’t technically need the schematics to do this work.

Really though, I think it’s fair to say even without in-depth technical analysis that the Unity wouldn’t exist without the FOCBOX, and the FOCBOX wouldn’t exist without VESC. The technical details aside it very much so fits the layman definition of derivative work.


That would be great, thanks for your interest in this project.

Definitely make a post about it, I’m sure there are other people who would apprecaite this too.


Is this a good time to mention the VESC was derived from instaspin? :exploding_head:


Always my friend!

Derivatives of derivatives of derivatives! How deep does this go?


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.


Maybe it’s time for a purist TI-ESC. That’s gonna need a fancy name though.


TEX-ESC??? :sunglasses:


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:


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.