Firmware

[lizardmech]

32 minutes ago, Tomek said:

I just took the controller I have apart and figured it's a no-name chinese chip (signed D7 1336KM4 18), so not much hope for reusing the controllers I already have.

For my current DIY project I think I'll get those controllers instead https://www.aliexpress.com/item/High-Quality-GREENTIME-15-Mosfets-48-84V-1500W-Dual-mode-Sensor-Sensorless-Brushless-DC-Motor-Controller/32218294528.html. They have reverse function, and should be able to run most EUC motors if I want to reuse them for something bigger, and I should be able to use them without (re)programming anything. @lizardmech for this project I don't have the $$ or time to go for TI instaspin, or VESC (VESC6 would be my choice of tech to explore). The main functionality will be anyways manual control (joystick connected via an external Arduino), but I'd like to play with self-balancing just for the fun of it. @electric_vehicle_lover, thanks for the tips, I have tons of Arduinos lying around, so I'll use what I have. When I'll have more time, I'll definitely buy one of the compatible KT controllers and try your firmware, but for this project I'll take a shortcut and just use the existing pre-programmed software.

The Ti dev kit + 2 motor drivers is cheaper though, even two chinese vesc clones are only marginally more than those. I don't really get why people think arduino + generic chinese controllers are easier doing it that way means no access to ERPM, current or duty cycle data for the balancing code. Multiple MCUs controllers could work if you write the firmware for everything so they can communicate with each other but operating the motor controllers as dumb components in an open loop makes no sense.

[Tomek]

53 minutes ago, lizardmech said:

 I don't really get why people think arduino + generic chinese controllers are easier doing it that way means no access to ERPM, current or duty cycle data for the balancing code. 

As I tried to explain before, for this project I only need simple control of 2 motors with a joystick and I don't have much time to invest, so a pre-programmed controller is perfect. Playing with self-balancing is only something I'll do on the side, but I've seen several projects that succeeded with self-balancing in such a setup. I'm not claiming that this setup makes ANY sense for a working and reliable EUC though. It's just a learning exploration.

An inspiration here: https://makezine.com/2016/11/14/hoverboard-electronic-skateboard/ (albeit I won't be making a skateboard, but an office cabinet on wheels - don't ask)

Edited February 19, 2018 by Tomek

[lizardmech]

19 minutes ago, Tomek said:

As I tried to explain before, for this project I only need simple control of 2 motors with a joystick and I don't have much time to invest, so a pre-programmed controller is perfect. Playing with self-balancing is only something I'll do on the side, but I've seen several projects that succeeded with self-balancing in such a setup. I'm not claiming that this setup makes ANY sense for a working and reliable EUC though. It's just a learning exploration.

An inspiration here: https://makezine.com/2016/11/14/hoverboard-electronic-skateboard/ (albeit I won't be making a skateboard, but an office cabinet on wheels - don't ask)

I get what you want to do but arduino + controllers should be more work and time not less than the other options. Assuming you use an arduino + generic ebike controllers you will have to run the balancing code, output 2 PWM signals and somehow level shift them to the voltage the range the controller expects, then you have to convert it into an analogue signal via a filter which likely introduces latency. Then rework the balance code to compensate for any latency or quirks with the controller inputs. Then even after all that is done the balance controller has no idea how fast the motors are turning and as torque and difficulty in remaining upright varies with speed I'm uncertain if the control loop can function reliably as an open loop system.

In comparison to doing it with MCUs that already have motor control code ready to go, all you need to do is get an IMU working via I2C, write the balance control loop and have it set the required torque value. If any compensation needs to be done for motor variables you have access to everything already.

[electric_vehicle_lover]

12 minutes ago, lizardmech said:

In comparison to doing it with MCUs that already have motor control code ready to go, all you need to do is get an IMU working via I2C, write the balance control loop and have it set the required torque value. If any compensation needs to be done for motor variables you have access to everything already.

I am pretty sure it can be done with EBike controllers running our OpenSource firmware, were the variables values for torque, motor rotation direction and motor current speed can flow over UART (the controller has wires with UART header because it uses a Bluetooth module). And since there is already working code for Arduino to UART and MPU6050, I think this aproach is a good idea for something to be done fast as prof of concept and to learn and have fun :-) 

Edited February 19, 2018 by electric_vehicle_lover

[Tomek]

Just now, lizardmech said:

I get what you want to do but arduino + controllers should be more work and time not less than the other options. Assuming you use an arduino + generic ebike controllers you will have to run the balancing code, output 2 PWM signals and somehow level shift them to the voltage the range the controller expects, then you have to convert it into an analogue signal via a filter which likely introduces latency. Then rework the balance code to compensate for any latency or quirks with the controller inputs. Then even after all that is done the balance controller has no idea how fast the motors are turning and as torque and difficulty in remaining upright varies with speed I'm uncertain if the control loop can function reliably as an open loop system.

I'm aware of all this (and converting PWM to analog - if needed - is not that hard http://www.instructables.com/id/Analog-Output-Convert-PWM-to-Voltage/). That's why I said, several times, I intend to just "play" with self-balancing on the side, since I'm already building this setup anyways for another purpose (for which even fully analog control would suffice). I really don't understand what point are you trying to make. Are you trying to tell me that I shouldn't waste a few hours of my time trying out self-balancing code in my setup (as I wrote before, obviously, not aspiring for it to be any reliable option for an EUC)?  That I shouldn't do my DIY project (that you know nothing about)? That I'm an idiot? All of the above?

@electric_vehicle_lover, avoiding such futile discussion is why I wanted to ask you in private about compatibility between the controller I have and your firmware, but you insisted otherwise...

[electric_vehicle_lover]

4 minutes ago, Tomek said:

 

@electric_vehicle_lover, avoiding such futile discussion is why I wanted to ask you in private about compatibility between the controller I have and your firmware, but you insisted otherwise...

I think things are more clear now. I don't have nothing more to say at this time, that can add value and I will ignore messages that don't bring value.

Looking forward to see what you can get. Would be great if you can share the tutorials, etc that you will be following as I would like to learn!

[lizardmech]

7 minutes ago, Tomek said:

I'm aware of all this (and converting PWM to analog - if needed - is not that hard http://www.instructables.com/id/Analog-Output-Convert-PWM-to-Voltage/). That's why I said, several times, I intend to just "play" with self-balancing on the side, since I'm already building this setup anyways for another purpose (for which even fully analog control would suffice). I really don't understand what point are you trying to make. Are you trying to tell me that I shouldn't waste a few hours of my time trying out self-balancing code in my setup (as I wrote before, obviously, not aspiring for it to be any reliable option for an EUC)?  That I shouldn't do my DIY project (that you know nothing about)? That I'm an idiot? All of the above?

@electric_vehicle_lover, avoiding such futile discussion is why I wanted to ask you in private about compatibility between the controller I have and your firmware, but you insisted otherwise...

All I'm suggesting if you want a quick and easy motor control solution arduino + chinese ebike controllers is perhaps the most difficult and time consuming way to go about doing it. Even for small little projects balancing or not. I have seen a decent arduino balancing robot but it had the arduino directly controlling the the power stage using LUTs to generate sinewave control as it was controlling the motors it was able to compensate for torque changes across motor RPM. 

[lizardmech]

23 minutes ago, Tomek said:

I'm aware of all this (and converting PWM to analog - if needed - is not that hard http://www.instructables.com/id/Analog-Output-Convert-PWM-to-Voltage/). That's why I said, several times, I intend to just "play" with self-balancing on the side, since I'm already building this setup anyways for another purpose (for which even fully analog control would suffice). I really don't understand what point are you trying to make. Are you trying to tell me that I shouldn't waste a few hours of my time trying out self-balancing code in my setup (as I wrote before, obviously, not aspiring for it to be any reliable option for an EUC)?  That I shouldn't do my DIY project (that you know nothing about)? That I'm an idiot? All of the above?

 

Also  why are you suddenly angry at me, you ask if the open ebike firmware has reverse (which it doesn't) and you said the existing controllers you own aren't viable, I don't quite get how trying to suggest cheaper and easier options as you wanted is somehow calling you an idiot?

[lizardmech]

1 hour ago, electric_vehicle_lover said:

I am pretty sure it can be done with EBike controllers running our OpenSource firmware, were the variables values for torque, motor rotation direction and motor current speed can flow over UART (the controller has wires with UART header because it uses a Bluetooth module). And since there is already working code for Arduino to UART and MPU6050, I think this aproach is a good idea for something to be done fast as prof of concept and to learn and have fun :-) 

It should work provided communication between the balance controller and motor controller is possible, the only thing that could become an issue is latency and timings on the various MCUs. I found this the other day, it was quite similar in function to colton code you adapted for your ebike stuff. Runs 2 BLDC + motors + balancing algo but the motor code and balance code were quite closely coupled as torque compensation was required. Still I think this is the only arduino balancing robot using 3 phase brushless motors I have seen that works quite well. The others I have seen always use DC or stepper motors, the brushless attempts were always very wobbly or only manage to work at 1kmh presumably due to torque compensation  issues. Another thing I found interesting from some open gimbal stuff is apparently 6 step BLDC is not viable for gimbals or balancing vehicles theres just too much cogging unless you build a motor with hundreds of poles.

http://www.instructables.com/id/Brushless-Gimbal-Balancing-Robot/

Though this robot looks pretty good I imagine there's a few things balancing vehicles would have to deal with, the robot has overwhelming amounts of torque for its weight so running openloop motor control is viable as there's no real chance of it de syncing. Secondly the faster EUCs may have to manage phase lag due to higher RPM. This matches up with EUC hardware. The early models are most likely running sensored LUT based sinewave controllers, while the addition of ACS current sense on 2 phases would make sense if they needed to switch to FOC to mitigate hall sensor issues and phase lag. It would be more obvious on EUCs as they have smaller wheels than ebikes but the same number of pole pairs resulting in higher ERPM, this would explain why they didn't just reuse existing ebike controllers. Even with high RPM middrive motors for ebikes they have far fewer pole pairs so electrical RPM is likely still quite low.

Edited February 19, 2018 by lizardmech

[Mystamo]

Guys,

Forgive me.. Also try not to overly flame me.

I've been MIA for a while.. Death in the family and killer busy.. Sneaking off at work to write this quick note..

What is the status of HW and SW build for EUC?  Last I left off about 2-3 years ago. EVL had some custom firmware spinning up a motor using generic 15km/h hw.

When I also left off I had posted the schematics of the 304B microworks board. Is that board still relevant and useful? I had it all reverse engineering minus the firmware ;D

In a nut shell what is the status of Custom firmware and hardware. I was always most interested in the ability to have one controller work with multiple wheels. This was the issue I always wanted sorted.

I quick summary would be endlessly appreciated.

Mo

[Hunka Hunka Burning Love]

You haven't missed much unfortunately.  Microworks stopped selling their board to hobbyists and fell off the face of the EUC world for a bit.  There was a brief announcement that they moved and were back in the game, but I haven't heard anything else from them.  I think Lizardmech mothballed his custom control board as he couldn't find someone to help program the firmware.  I haven't seen @electric_vehicle_lover posting for a while, but he still visits.  @MattJ hasn't released any home made wheels that I have seen lately.

 

http://microworks.en.alibaba.com/company_profile.html#top-nav-bar

Edited May 1, 2018 by Hunka Hunka Burning Love

[lizardmech]

4 hours ago, Mystamo said:

Guys,

Forgive me.. Also try not to overly flame me.

I've been MIA for a while.. Death in the family and killer busy.. Sneaking off at work to write this quick note..

What is the status of HW and SW build for EUC?  Last I left off about 2-3 years ago. EVL had some custom firmware spinning up a motor using generic 15km/h hw.

When I also left off I had posted the schematics of the 304B microworks board. Is that board still relevant and useful? I had it all reverse engineering minus the firmware ;D

In a nut shell what is the status of Custom firmware and hardware. I was always most interested in the ability to have one controller work with multiple wheels. This was the issue I always wanted sorted.

I quick summary would be endlessly appreciated.

Mo

I built a bunch of different motor controllers, after various explosions and fires I got enough practice that I can design and build them without much effort so there's not really any need for microworks or chinese controllers in general. EVL was hostile towards use of any open source hardware and stopped working on anything EUC related when microworks stopped selling EUC boards.

I managed to get most of the code needed to make an EUC, it really just needs different parts to be assembled into one firmware. I still haven't been able to find anyone to help with software development though, I don't think anyone was willing to contribute even a single line of code over the last 2 years.

[Mystamo]

What the heck.. That is sad.. Also, I really still see a need for this.. What the heck do I do if I ever blow up my controllers now in my 15km/h and 30km/h EUC.

I'll post my schematics for the 304B board.. I had costed and BOMed out that board. It was cost effective and simple enough as a good enough foundation to start with.

We can get back into it and have a look at your code.

EVL was a bit nuts to be honest. Always a bit hostile and most of the reason why I originally kinda flaked off and left. Smart but only willing to do it his way or the highway.

What was wrong with just open source stuff with everything available without getting into all this open commons licenses and crap. .To me, open source means the person who made it shares it and doesn't care if people try to make money or whatever off of it.. It's all open. if you have the initiative to find a way to make money from technology that is available to you and everyone. Then Kudos and that's open source.

 

Mo

[lizardmech]

14 hours ago, Mystamo said:

What the heck.. That is sad.. Also, I really still see a need for this.. What the heck do I do if I ever blow up my controllers now in my 15km/h and 30km/h EUC.

I'll post my schematics for the 304B board.. I had costed and BOMed out that board. It was cost effective and simple enough as a good enough foundation to start with.

We can get back into it and have a look at your code.

EVL was a bit nuts to be honest. Always a bit hostile and most of the reason why I originally kinda flaked off and left. Smart but only willing to do it his way or the highway.

What was wrong with just open source stuff with everything available without getting into all this open commons licenses and crap. .To me, open source means the person who made it shares it and doesn't care if people try to make money or whatever off of it.. It's all open. if you have the initiative to find a way to make money from technology that is available to you and everyone. Then Kudos and that's open source.

 

Mo

There's not much to those microworks boards, they use older components that be replaced, some of the solutions on them are convoluted and add many components. For example they use a 5v allegro current sense that doesn't have enough sensing range so they try and use either PCB fill or a resistor to divide the current, then they take the 5v signal and have to use a voltage divider to convert it to 3.3v signal for the MCU. Now allegro make a small SMD current sensor with 100A+/- range and 3.3v output.

Software wise all that really needs to be done is add IMU support to existing motor control options, I played around with VESC, Ti instaspin, STM FOC and NXP FOC software. VESC is the most open but difficulty when it comes to modifying it is extreme due to no real documentation and it is quite complex due to the amount of features. Texas instruments Instaspin seemed the best of the commercial options, it almost completely open, there's a small motor control library on the MCU you can't access but anyone can edit and build the rest without any restriction. STM software was similar but a little behind the Ti option in features and performance while not having as much documentation or convenient cheap dev kits to use. 

[Mystamo]

6 hours ago, lizardmech said:

There's not much to those microworks boards, they use older components that be replaced, some of the solutions on them are convoluted and add many components. For example they use a 5v allegro current sense that doesn't have enough sensing range so they try and use either PCB fill or a resistor to divide the current, then they take the 5v signal and have to use a voltage divider to convert it to 3.3v signal for the MCU. Now allegro make a small SMD current sensor with 100A+/- range and 3.3v output.

Software wise all that really needs to be done is add IMU support to existing motor control options, I played around with VESC, Ti instaspin, STM FOC and NXP FOC software. VESC is the most open but difficulty when it comes to modifying it is extreme due to no real documentation and it is quite complex due to the amount of features. Texas instruments Instaspin seemed the best of the commercial options, it almost completely open, there's a small motor control library on the MCU you can't access but anyone can edit and build the rest without any restriction. STM software was similar but a little behind the Ti option in features and performance while not having as much documentation or convenient cheap dev kits to use. 

/

Hey,

So let me just get you to clarify a few things for me.

Is the MCU and bridgedriver combined? What microcontroller is best to use. Those what you mentioned above?

If the bridge driver is not included in the MCU. what bridgedriver is used.

How is the H bridge configured? Filters, dead times, current sense shunts. Does the bridge driver just take care of most passive components?

What IMU is being used? 6050? Aren't there massive amounts of avail lib and documentation for this chip? Advanced controls and filters.  I think we could just pull from quad copter control system source codes readily avail from multiple open sources.

What are you using the program the MCU what does the IDE environment look like? Useful debugging tools?

Lets get this thing back up and going I feel motivated.

As far as I'm concerned. HW is the least concerning part.. I think you agree.  I'm not a stellar programmer. But I'm super resourceful, have access to proficient programmers and can do a hell of a cut a paste job on available code to make stuff work.

 

Mo

 

 

Mo

[lizardmech]

This is the MCU I have been mostly using, the dev board has a debugger on it. Ti has there own eclipse IDE and gcc fork so it's easy to develop for them these days, you just download their code composer studio thing off the Ti website and it's more or less ready to use with all the needed debug and compiler settings configured. 

http://mouser.com/ProductDetail/Texas-Instruments/LAUNCHXL-F28069M?qs=%2fha2pyFaduiQ7Z42YDZKD5QyyhA%2bSpny8iXDynuyzWmTbS83j4JizA%3d%3d

You can plug it directly into this, the voltage and current limit is a bit low to ride an EUC but it spins the motor and is enough for basic testing.

http://mouser.com/ProductDetail/Texas-Instruments/BOOSTXL-DRV8301?qs=sGAEpiMZZMtjWZqwEMjY%2f2%2f690yOn8Q3JTTEZ%2fhpAs8%3d

I was just using the MPU6050 as it was common, most code examples I have seen don't end up even using the processing on the mpu6050, they usually just use a kalman filter on the main MCU to combine gyro + accel. The mpu6050 looks like its close to EOL though there's still plenty of stock around and there's more or less a drop in replacement, it's probably fine to keep using it, I had someone write drivers for it on a STM32 mcu when I was trying to get the VESC to work, it shouldn't be hard to move it to the Ti MCUs. 

For the inverter section it's pretty much gate driver + 2 mosfets and current sense for each phase. The chinese boards tend to use gate drivers with only one PWM signal per gate driver, the gate driver is responsible for deadtime and it can't be adjusted in software, all the ones, all the ones I built have separate high and low side PWM inputs so you can set the deadtime in firmware. Generally the gate driver to mosfet gate pin traces are the most sensitive part, they need to be as close as possible and you have to avoid making large ground loops. Another few tricks is putting a diode in parallel to the gate resistor to speed up turn off since you don't have to worry about ringing, another is to place a ferrite bead near the mosfet gate, they basically look like a very large resistor to high frequency AC but allow the PWM signal to travel through. Generally a small resistor + ferrite bead is better than increasing gate resistor resistance.

The only other thing I can think of is you need phase voltage sense which isn't on the microworks boards, you just use a simple resistor divider to scale the voltage for the MCU to read, it must however have a low pass filter to reject PWM signals, this part drove me crazy only the instaspin controllers rely heavily on it so I never noticed the need for the filters on early designs and was constantly looking for other problems which didn't exist. Another trick I found from some of the instaspin reference designs is to protect the MCU analogue inputs with TVS diodes, that way the non-isolated voltage senses won't kill the MCU in the event of an unexpected voltage spike. 

Edited May 2, 2018 by lizardmech

[KingQueenWong]

Anybody focus on "hovershoes"?

[Alex12]

Hi,

I've the same unicycle as yours. I connected my st-link and erased all the software in it accidentally. I would like to know if you still have the software. If yes, is it possible to give me a copy [if you don't mind oc ]

thanks a lot in advance 

Alex 

[Lefteris]

I know it's an old thread but, i've hit a dead-end and i was just started

I'm trying to read the latest _Main.bin (direct link) of the latest firmware of LeaperKim Veteran Sherman OTA update apk (link by nytarzan) and my pure English version of that apk that i forked here (Our forum link, Nothing Chinese inside ).

I find the following : 

1. The firmware is small in size, like ~44kb
2. by using strings you can see that there are a lot of places that usual variables popup
3. when using binwalk to check things out i get an empty screen

Any ideas on how to "walk" thru this, maybe insert it on IDA ?

It seams like it's pure data, no header or any pointer on what starts where...

[Lefteris]

So it uses the MPU6050 and i didn't saw that..

will read more about it..

edit: guys here found that the .58 has exactly 27 option screens

Will search more about it..

Edited July 11, 2021 by Lefteris

[Stanley Ravi]

On 9/4/2015 at 6:43 PM, jayjay23 said:

I've bought a generic EUC and found the speed limit to be a bit annoying, still being aware there will be any kind of hardware limitation (battery (voltage drop), motor heat, controller heat).
As a software developer being a little into hardware as a hobby I thought it would be great to have the firmware at hand and do any kind of adaptation possible (reading more of this forum also some security aspects like cut off could be tuned).

So I questioned myself whether it may be possible to do it just by owning the hardware as I don't expect to find anybody at all and somebody finally willing to share the code.
When opening it for installing a bicycle computer I had a look at the controller and it uses a STM32 (F103C8T6) controller for which I could find the manual with all information like
pinout etc.

 

Searching for whether the flash can be written 'and' read I found that it's possible as long as there has been no explicit read lock set by the manufacturer. As I hope that this is not the case I diged further and found that the interfaces this STM32 should have for programming is some serial interface and a JTAG (being on the same PINs and automatically switched).

The spec. for the chip clearly states which PINs these are and if somebody every looked into the world of firmwares (e.g. OpenWRT) for wireless routers, it seems standard that some of the programming/debugging interfaces are just left on the board, so it's the same case for my controller board:

 

Fortunately I still don't own a JTAG adapter, but now one is ordered. I also found an interesting paper from blackhat conference showing available tools, JTAG finding and some more (https://www.blackhat.com/presentations/bh-europe-04/bh-eu-04-dehaas/bh-eu-04-dehaas.pdf)

So this is were I'm currently, quite at the beginning, but I would like to know if anybody has some input or ideas to contribute.

This could fast also be a dead end road but let's see, if the image can be read (I will first try with openOCD) it should be possible to disassemble and decompile, maybe it will be hard to recompile it, but maybe some things can be adjusted by just working on the raw image.

If there is some progress I will add it here.

EDIT (16.09.2015): Replaced image showing debug connector to show now used SWD (Serial Wire Debug) pin out (STM32 also has JTAG but on my board layout two of the JTAG pins are used for the power LEDs, so they are redefined as GPIO, while SWD works fine).

This 2024 and you still seem way ahead of your time. I am digging to just replace/fix the main board. Any help will be highly appreciated. +919502044255

[Stanley Ravi]

On 9/16/2016 at 2:00 PM, electric_vehicle_lover said:

I bought 3 x 30B4 boards for development. I also have 2 working EUCs with that boards (in total I bought 5 x 30B4 boards).
For motor, I am using one motor from an old generic. I have in total 4 motors with me but 3 of them on working EUCs.

There is no file for original firmware.

Can I get a 30B4 board?