Motor Controller with Customizable Electronics, easy DIY and repair OpenSource

[afzal]

Would you mind to put your files on https://github.com/OpenSourceEBike organization? and I would consider this version the latest version of hardware and the previous one was a step to get to this point.

No problem, how should I proceed ?

I would like to have it reviewed as well.

Gerbers easy to compare with the ones generated by EasyEDA is attached. Also the BOM and pick & place suitable for JLCPCB assembly, components not part of SMT assembly has been excluded from it. These has been not pushed to repo as git has been instructed to ignore some of the generated files.

And do you plan to assembly and test the board?

I was undecided, most probably going to do it.

Then you could also put some notes / document on https://opensourceebike.github.io/, writing a specific page(s) for this hardware.

Okay

I am sorry but I can not help on the firmware side. I am being to busy on my life.

No issues, I can handle the firmware for myself. I believe there are a few suitable firmware's already available in public.

I had been in the works of a similar hardware architecture for selfish reasons , mainly driven by semiconductor shortage & it's associated problems. And I had learned much from this project.

 

[mxlemming]

Hi Afzal,

Glad someone is finding a use for this.

We have largely moved on to the bigger MP2 also on this forum, since the interest from the high power 5+kW devices crowd seems higher. That said, this board did work pretty well for me... But I'm the only person who tested it.

With casainho no longer supporting the firmware, the other available firmware is mine and stancecoke... But only mine has ever been run on it AFAIK. May also be possible to put OWhite's F405/VESC pill on it...https://github.com/davidmolony/F405_pill

I would highly recommend you copy the phase detection from the MP2 if you intend to run my firmware or the VESC variants. That is, 100k and 3k3 divider (with a jumper and a small capacitor?) on each of the phases going to pill pins 11,12 and, 14. This enables reliable freewheeling and fault recovery.

I cloned your project and opened it, very very cursory look... I will leave Badgineer to make his comments. It looks like a faithful replica of the original, which is a good start. Did you reroute it manually or use an import tool of some kind?

1) There is no need for the thick digital and analog signal traces, IIRC they were used in the original, but that is something of an EasyEDA thing, so if you need more room, decrease to 0.2mm.
2) You might consider reassigning all the pins on the pill to be identical to the MP2/CCC if Casainho is never going to support this in his code.
Now, the two biggest irritations from someone who built one...
3) You might consider replacing the 12-5V reg with one of those switching 7805 replacements, just for great availability. Likewise, the 100-12V reg might want a bit of thought, the original Aliexpress part when I received it was no good and I had to bodge on another DCDC. Label the DCDC pins... 100V ready DCDCs are a bit of a PITA, not many and the ICs are a bit flakey.
4) The biggest irritation was not being able to fit the DC bus caps between the FETs and the pill. give that a moments thought, but I think Badgineer might have fixed that since?
5) More ADC channels... consider the CD4051 Mux for non FOC related activities?

 

[casainho]

Would you mind to put your files on https://github.com/OpenSourceEBike organization? and I would consider this version the latest version of hardware and the previous one was a step to get to this point.

No problem, how should I proceed ?

Hmmm, forgot that the files were already on EBiCS, so, the best way is to keep this most recent version there: https://github.com/EBiCS/EasyDIY-ESC

Can you tell me your user on github so I can add you as a member?

So the previous version was 0.5.2: https://github.com/EBiCS/EasyDIY-ESC/tree/feature/v0_5_2
So I think is good to just replace all files with your new files, on main branch and so the 0.5.2 will have his backup on that feature/v0_5_2 branch. Then we should also update the README current state to identify that main branch is in development and there was a change to use KiCad:

 

[afzal]

Hi David Molony,
[ hope I got your name correctly ]

Glad someone is finding a use for this.

We have largely moved on to the bigger MP2 also on this forum, since the interest from the high power 5+kW devices crowd seems higher. That said, this board did work pretty well for me... But I'm the only person who tested it.

I have been following both threads, :thumb:

With casainho no longer supporting the firmware, the other available firmware is mine and stancecoke... But only mine has ever been run on it AFAIK. May also be possible to put OWhite's F405/VESC pill on it...https://github.com/davidmolony/F405_pill

I would highly recommend you copy the phase detection from the MP2 if you intend to run my firmware or the VESC variants. That is, 100k and 3k3 divider (with a jumper and a small capacitor?) on each of the phases going to pill pins 11,12 and, 14. This enables reliable freewheeling and fault recovery.
2) You might consider reassigning all the pins on the pill to be identical to the MP2/CCC if Casainho is never going to support this in his code.

Okay, this is good info, let me go through the available firmwares

I cloned your project and opened it, very very cursory look... I will leave Badgineer to make his comments. It looks like a faithful replica of the original, which is a good start. Did you reroute it manually or use an import tool of some kind?

It was manual routing. Intention was to replicate as is as much as possible in KiCad and then modify/optimize, the reason custom footprints had to be made even for those in standard KiCad library (intention is to replace it with standard footprints in KiCad library).

1) There is no need for the thick digital and analog signal traces, IIRC they were used in the original, but that is something of an EasyEDA thing, so if you need more room, decrease to 0.2mm.
Now, the two biggest irritations from someone who built one...
4) The biggest irritation was not being able to fit the DC bus caps between the FETs and the pill. give that a moments thought, but I think Badgineer might have fixed that since?

Yeah, I noticed this. Once I started, realized that to complete conversion ASAP, it is better to shut eyes to any modifications felt and just replicate. Once it is complete then do any value addition.

3) You might consider replacing the 12-5V reg with one of those switching 7805 replacements, just for great availability. Likewise, the 100-12V reg might want a bit of thought, the original Aliexpress part when I received it was no good and I had to bodge on another DCDC. Label the DCDC pins... 100V ready DCDCs are a bit of a PITA, not many and the ICs are a bit flakey.

Noted, thanks

5) More ADC channels... consider the CD4051 Mux for non FOC related activities?

Okay, if requiring more channels, this info will be helpful.

Thank you for the feedback

 

[afzal]

Can you tell me your user on github so I can add you as a member?

afzalmam

So the previous version was 0.5.2: https://github.com/EBiCS/EasyDIY-ESC/tree/feature/v0_5_2
So I think is good to just replace all files with your new files, on main branch and so the 0.5.2 will have his backup on that feature/v0_5_2 branch. Then we should also update the README current state to identify that main branch is in development and there was a change to use KiCad:

Okay

 

[casainho]

Can you tell me your user on github so I can add you as a member?

afzalmam

So the previous version was 0.5.2: https://github.com/EBiCS/EasyDIY-ESC/tree/feature/v0_5_2
So I think is good to just replace all files with your new files, on main branch and so the 0.5.2 will have his backup on that feature/v0_5_2 branch. Then we should also update the README current state to identify that main branch is in development and there was a change to use KiCad:

Okay

You should have write access now. So go and replace all the files on main branch with yours.

 

[afzal]

You should have write access now. So go and replace all the files on main branch with yours.

Done

 

[afzal]

I would like to have it reviewed as well.

ATM, I am looking more of a review on comparison with the latest EasyEDA project - like is it similar enough to consider it an equivalent?, are there any mistakes as compared to the existing?. I had this in mind while mentioning above, but re-reading I realize that it should have been expressed in words as well.

Thinking was once this reaches parity with the latest EasyEDA one (v0.5.2), then we can take it from there and do the modifications, optimizations etc as a next step in the continuous process.

Though I already made one change, made the edges round, I couldn't stand the sharp edge

 

[afzal]

@badgineer, I see that you updated the README, thanks!, some more changes (trivial) were pushed so that layout is a better duplicate of yours :wink: (except for the round edges). Version number hasn't been yet added, it would be great to know your opinion

 

[casainho]

I am now in favor of VESC, just because VESC is so popular and powerful. So, my suggestion is for the hardware developers to think if is possible to update this concept of Easy DIY and repair OpenSource ESC, to be as the VESC hardware so the VESC firmware can be used directly.

Some of my notes about VESC:

Example of VESC EBike motor controller: Flipsky VESC 75100 EBike controller: 100€, 75V 100A, CAN and UART communication.

Advantages:
- BEST motor controller out there, OpenSource, small and powerful
- only 1 minute to make the inital motor auto detection setup, resulting in the best motor performance and silence out there!!
- VESC EBike application can be developed in high level scripting language
- powerful mobile app (also for PC and RaspberryPI), with high level scripting language for custom application
- display available to buy on shops, OpenSource (although for ESkates but easy to adapt for EBikes)
- there are A LOT of experienced users / developers of VESC
- powerful advanced algorithm for sensorless at motor 0 speed meaning no hall sensors needed

Disadvantages:
- not as cheap as the chinese EBike motor controllers although cheap enough since the chinese also sell VESC controllers (Flipsky is chinese)

Video:

[youtube]H-6qzmeCNtw[/youtube]

 

[stancecoke]

VESC EBike application can be developed in high level scripting language

This is the main disadvantage of the VESC! It's not suited for EBike use at the moment. There is a basic PAS implementation that's it.
There are forks with Bafang Display Protocol implemented from Luna Cycle I think, but I'm not sure....

This controller uses VESC firmware however only a few of the settings will be user adjustable to prevent the user doing inadvertent damage to the controller.

VESC hardware is definitely not the way, I would go. Way too expensive and no advantage over the Lishui Controllers for EBike use...

regards
stancecoke

 

[casainho]

VESC EBike application can be developed in high level scripting language

This is the main disadvantage of the VESC! It's not suited for EBike use at the moment. There is a basic PAS implementation that's it.
There are forks with Bafang Display Protocol implemented from Luna Cycle I think, but I'm not sure....

This controller uses VESC firmware however only a few of the settings will be user adjustable to prevent the user doing inadvertent damage to the controller.

VESC hardware is definitely not the way, I would go. Way too expensive and no advantage over the Lishui Controllers for EBike use...

Maybe the best way is to use VESC is as a standalone motor controller and send the motor control commands by either UART or CAN. Then have a second board specifically for the application, like for EBike, ESkate, Electric Unicycle, Motorcyle, etc. That board is needed for the custom / specifics of analog electronics of the application, and can have a microcontroller that is easier to program, in an higher level language as Python!! (or C++). There are a few popular like Raspberry PI Pico, ESP32, NRF52840 or any other ARM board where CircuitPyhton runs.
Higher level language as Python means it would be easier and fast to develop, as also easy for any software developer join, and not only for embedded firmware developers, that are hard to find.

Searching for VESC and Lishui motor controllers, on Youtube and Aliexpress, it is very clear what is the most popular and has more options.

 

[stancecoke]

it is very clear what is the most popular and has more options

very popular and very useful is not the same :wink:
Of course the VESC has tons of options, but not for EBike use. Do you need a nunchuck on your bike ?!
Having a precontroller (like the very mature "Forumscontroller") means having additional tinkering with PCBs and wiring.

With using a controller, that is made for an Ebike, you need no additional hardware, you have controller geometries that fit in the battery housing, waterproof connectors, commercial displays..... The only thing you have to tinker is an USB-UART converter with a 5 pin Higo to flash a custom firmware via the display connector.
Millions of EBikes in the EU are equipped with Lishui controllers by the OEMs, so you won't even have to change any hardware.

regards
stancecoke

 

[casainho]

it is very clear what is the most popular and has more options

very popular and very useful is not the same :wink:
Of course the VESC has tons of options, but not for EBike use. Do you need a nunchuck on your bike ?!
Having a precontroller (like the very mature "Forumscontroller") means having additional tinkering with PCBs and wiring.

With using a controller, that is made for an Ebike, you need no additional hardware, you have controller geometries that fit in the battery housing, waterproof connectors, commercial displays..... The only thing you have to tinker is an USB-UART converter with a 5 pin Higo to flash a custom firmware via the display connector.
Millions of EBikes in the EU are equipped with Lishui controllers by the OEMs, so you won't even have to change any hardware.

The idea of using VESC is recent to me and did happen when a Bafang developer started to develop a controller based on it. This developer already built other devices using it, so he has a good experience. So it was a natural choice and I am happy to have other experienced developers developing, and I just need to join them.

For my needs, TSDZ2 EBike, Bafang EBike and Xiaomi EScooter, there is no ready hardware that will fit to that ones, there are specifics that need to be done for each, and then it will be DIY.

In the end, I think it needs to be like this, with room for that DIY board:



Based on my experience, the motor code is complex and critical, and is difficult and risky to add an EBike application there or any other user application. For that, the developer needs to be very experienced in firmware (which is hard to find) and is a big risk to burn in fire the controller while developing. Since the extra board is mostly always need, and since small microcontrollers boards for DIY are cheap and powerful, we can isolate the motor controller code and let the developer just play with an high level language, inside a safe box, with advantages for faster development due to the high level language and because this box will be a popular well known one.

The way I see this project would be the same board as seen on the picture, but based on VESC. The only advantage over using an already existing VESC + extra DIY board connected by UART, is because this project board is easy to repair.

 

[stancecoke]

the motor code is complex and critical

Working and reliable FOC motor control code can be generated by the ST Motor Control Workbench with just a few clicks in a graphical user interface. Nevertheless, mxlemming, myself and others have each developed our own reliable FOC codes. This is not witchcraft.
But no need to argue, everyone should go his preferred way...

regards
stancecoke

 

[casainho]

the motor code is complex and critical

Working and reliable FOC motor control code can be generated by the ST Motor Control Workbench with just a few clicks in a graphical user interface. Nevertheless, mxlemming, myself and others have each developed our own reliable FOC codes. This is not witchcraft.

That was not my point.

There are different ideas here:
1. use or not use VESC firmware
2. put the ESP32 (or similar) on the DIY expansion board, to work as a sandbox and develop in Python or C++ the user application like for an EBike

VESC developer is taking a similar path, but including that sandboxed directly on the motor controller firmware - maybe this description helps do understand this new ideas:

One of the main new features for this release is scripting support on the vesc hardware using the old-but-still-useful language Lisp.

The intention is to make the scripting as simple as possible and have it completely sandboxed so that you cannot brick the vesc by uploading code that gets stuck, runs out of stack, writes to bad memory locations etc. So far is seems quite solid, but there is a lot of work left to make new features, examples and hopefully some documentation.

The reason for the scripting is to make it easier to connect different VESC-supported hardware (and others too with a bit more code) modules together and build e.g. an electric motorbike that has an IO-board controlling indicators, brake light, speed modes etc. You can already do this with custom applications, but then you have to get the entire toolchain up and running, get a debugger, understand how to compile the correct firmware, not interfere with other critical parts of the vesc code from your code and so on. The Lisp scripting is already in vesc tool, takes care of memory management (garbage collection) and dies nicely when something is wrong in the code.

 

[mxlemming]

If you want to run VESC on this board it's already easy, you just use the F405 pill designed by ES user OWhite and tested extensively on the MP2 ESC.
https://github.com/davidmolony/F405_pill
For some reason it's on my github not his... But full credit to OWhite.

The original hardware can be used with full VESC and MESC functionality with 6 resistors to make phase sensors and i think the latter KiCAD version Afzal is writing on will support this natively.

VESC is not the best motor controller, it had an amazing interface and a bazillion options but the underlying FOC is very similar to the reference implementations, with serious limitation on PWM frequency and for reasons not currently understood by the community a higher than necessary rate of self destruction (there have been significant improvements in the later releases on this front).

 

[casainho]

If you want to run VESC on this board it's already easy, you just use the F405 pill designed by ES user OWhite and tested extensively on the MP2 ESC.
https://github.com/davidmolony/F405_pill
For some reason it's on my github not his... But full credit to OWhite.

The original hardware can be used with full VESC and MESC functionality with 6 resistors to make phase sensors and i think the latter KiCAD version Afzal is writing on will support this natively.

VESC is not the best motor controller, it had an amazing interface and a bazillion options but the underlying FOC is very similar to the reference implementations, with serious limitation on PWM frequency and for reasons not currently understood by the community a higher than necessary rate of self destruction (there have been significant improvements in the later releases on this front).

Good to know and you guys are very active. Myself, I will focus more and more on high level.

 

[afzal]

Making this board being compatible with MP2 ESC is on my mind, so that one can put blue/black/F405/<whatever your> pill onto either MP2 ESC or this board to achieve desired functionality, power and run variety of firmware's including VESC.

Reg cost, at Digikey, 405RGT6 (VESC uC) costs double that of 103C8T6 (bluepill uC), around $15 vs $7.5, but as usual no stock. And comparing the prices in LCSC & Aliexpress, I got disoriented , in LCSC today it is showing $19 vs $3, with Ali, I am not able to make a clear comparison.

And an update, I had ordered for SMT assembly of this board corresponding to git tag v0.5.x (current HEAD of main branch)

 

[agentdjs]

Hi!

I am considering porting MESC to a dual core MCU and adding the following

1). dual motor & dual encoder
2). eDifferential (using two motors)
3). max17841 bms monitoring
4). automotive two wire ethernet

The github README lists a few steps towards that goal.
https://github.com/davidmolony/MESC_Firmware#porting-to-other-mcus
Would you say that was still about right?

 

[mxlemming]

Hi!

I am considering porting MESC to a dual core MCU and adding the following

1). dual motor & dual encoder
2). eDifferential (using two motors)
3). max17841 bms monitoring
4). automotive two wire ethernet

The github README lists a few steps towards that goal.
https://github.com/davidmolony/MESC_Firmware#porting-to-other-mcus
Would you say that was still about right?

What dual core MCU?

It's roughly right in the readme but recently I've made big changes, including the ability to easily support dual motors.

Dual encoder might be trickier owing to the SPI read time for an absolute encoder. It's probably fine if you stay down in the 15khz pwm region. I've never used an incremental one, purely lack of owning one.

The concept for MESC firmware is that everything should be modular, the project as a whole should still run without the modules included. Thus a max bms module might look something like:
Include a header file in main
Run an init with pointers for the hardware peripherals needed
Add something to the while 1 or allocate a low priority timer interrupt to call it periodically.

If you don't include the header, it should all be stable and work and compile without it.

 

[agentdjs]

Thanks!

I'm working on a controller for dual motors so I'm pleased there is support there. It would be good to be able to wrap one or two motors into a 'drivetrain structure' and apply an electronic differential. Ultimately four motors / all wheel drive traction control. A master MESC and slave MESC communicating over 2 wire time sensitive ethernet.

The board is currently 65x85mm - MCU is from Renesas. Happy to send one to MESC devs once printed/assembled. I'm still pin planning and mulling over how best to accommodate various position /encoders.

Also, the MCU has a Trigonometric Function Unit (TFU) to accelerate dq conversion process - without the need for lookup tables.

I used these enocders at the moment. They have a fancy tool to set them. The MCU has its own dual encoder h/w interfaces.
https://www.quantumdev.com/products/optical-encoders/qm35-ez-comm/

As for BMS - I've made my own 8S monitors from the MAX17843.

Do you have a Discord or Matrix ?

Just reviewing your HFI_Dection branch. I have some questions.

 

[afzal]

A master MESC and slave MESC communicating over 2 wire time sensitive ethernet.

EtherCAT?

MCU is from Renesas.

RZ/T2M?

I'm still pin planning and mulling over how best to accommodate various position /encoders.

Which encoders?

Feel free to ignore if answering in public is a problem

 

[hinxx]

It is different, yes, but I set the low side PWM polarity to inverted already. PWM works, open loop run works also, but the phase current is not measured properly obviously. Regular ADC works, injected ADC seems to be the problem.

regards
stancecoke

@stancecoke I was tinkering with the code in the EBiCS_motor_FOC repo for the last couple of days and managed to get my ecoride to run "smooth" during the autodetect and with the throttle. There were some subtle differences in the TIM1 channel 4 between EBiCS_motor_FOC and EBiCS_Firmware that I had to copy over in order to get here. With that the injected phase currents are readout properly as it seems. See Commits · hinxx/EBiCS_motor_FOC if you're interested.

Here is the video of the flash, autodetect and throttle control:

At the end of the video you can see the throttle (potentiometer on the breadboard) ADC readout prefixed with 'T' and how its level effects the wheel speed slowing down (heard in the background). As I'm listening to the the wheel now, sounds like it is clunking and rattling badly, but this is like it is even with the stock firmware

I find the EBiCS_motor_FOC code base more readable and nicely isolated of all the bike specifics. I'm thinking on hacking this one while trying to figure better flux weakening settings.