Firmware

[RolluS]

Very good project @lizardmech.

How will it work with this EUC custom firmware?

 

[lizardmech]

10 hours ago, RolluS said:

Very good project @lizardmech.

How will it work with this EUC custom firmware?

 

I don't think custom firmware will be possible on existing hardware. They don't have the components needed to detect motor configurations. You would have to purchase another controller or equipment to determine the motor values then manually code them into the firmware.

[electric_vehicle_lover]

The MicroWorks board have Bluetooth communication and firmware can be flashed by the mobile app.

1st firmware would run to detect the motor parameters and pass that information to the app

2nd firmware, the final one would include the previous information for the specific motor.

This is 2 steps but the same is done on VESC firmware but VESC firmware is only 1 firmware and not divided in 2 parts.

We could have ready firmware for specific motors included on the app.

Edited October 7, 2016 by electric_vehicle_lover

[lizardmech]

How will you profile the motor without phase voltage sense though?

[Tomek]

On 10/6/2016 at 1:46 PM, lizardmech said:

VESC 6 still has the DRV8302 that struggles above 50V and blows up because its gate drive current is too weak if you abuse it.

are you still using 6EDL04N06PT as a replacement in your current board? is it complicated from a hardware point of view to swap DRV8302 for 6EDL04N06PT (or whatever you're using now)?

Edited October 7, 2016 by Tomek

[lizardmech]

5 minutes ago, Tomek said:

are you still using 6EDL04N06PT as a replacement in your current board? is complicated from a hardware point of view to swap DRV8302 for 6EDL04N06PT (or whatever you're using now)?

I switched to analogue devices ADUM 7223, they're isolated 4 amp driver pairs in a small 5mm x 5mm package, the only terrible thing is soldering them by hand. In comparison the 6EDL04N06PT and DRV8302 current is 0.3 amp with no isolation so they usually destroy every component on the board if they break. There's no dead time or shoot through protection so the MCU must do that.

 

[lizardmech]

The most difficult part was the current sensing. To get good FOC performance you need fast and accurate sensors. Most shunt based sensors can only handle between 60-80v. Magnetic sensors are less accurate. There's a bunch of high end sensors suited for the task, MCU manufacturers conveniently leave the feature needed to read them off on all their products with motor control software. I had a ukranian freelancer help me out designing a work around to allow more basic MCUs to read them, seems to work nicely. 

[electric_vehicle_lover]

2 minutes ago, lizardmech said:

How will you profile the motor without phase voltage sense though?

I must say that I am not sure but, for my current understanding, for having FOC sensorless we need the estimator and the estimator needs to know resistance and inductance of the motor coils (for having BEMF value.. ??). Resistance is measured using voltage (supply voltage * pwm duty_cycle) and coil/phase current. Inductance I think is measured counting the time between a pulse of voltage and pulse of current. More inductance, more time the current will take.

So I believe measuring voltage input (batter voltage) and current is enough for measuring resistance and inductance of the motor coils and so having the estimator working for the sensorless FOC. I will keep learning with VESC sources and the many articles over the web.

[lizardmech]

I think you need phase voltage sense because you send pulses through one phase then measure voltage drop on another. In theory you might be able to have low side voltage sense + vbus but you're going to need voltage measurements in two places to work out resistance.

[lizardmech]

I played around with sensorless control a little more, not sure if a sensorless EUC is possible, I got it pretty close to how it behaves with hall sensors.

 

[electric_vehicle_lover]

From my understanding, it always uses hall sensors (for quick start and quick direction change) and always go in sensorless mode after some "medium" speed.

[lizardmech]

No that is completely sensorless mode, hall sensors were unplugged.

[electric_vehicle_lover]

2 minutes ago, lizardmech said:

No that is completely sensorless mode, hall sensors were unplugged.

I understand from your video - thanks for experimenting and sharing. We can see some "oscillation" when the motor change rotation (and that was without a load) that should be a blocker for EUC application.

[lizardmech]

12 minutes ago, electric_vehicle_lover said:

I understand from your video - thanks for experimenting and sharing. We can see some "oscillation" when the motor change rotation (and that was without a load) that should be a blocker for EUC application.

Not sure, I thought so to at first but it only occurs starting from 0 RPM. Going from 200 rpm to -200rpm is flawless. On a hoverboard it would be a problem because they start from a stand still while EUC rarely sit at 0 RPM. The next firmware might have better performance as well.

[electric_vehicle_lover]

For me, the balance on hoverboard and and EUCs are equal, just hoverboard have 2 independent wheel/motor.

When in balance, the EUC is almost only stopped / zero speed.

[Tomek]

5 hours ago, lizardmech said:

 I had a ukranian freelancer help me out designing a work around to allow more basic MCUs to read them, seems to work nicely. 

software or hardware workaround? did you have to make (m)any changes in VESC firmware to run with your board?

[lizardmech]

6 hours ago, Tomek said:

software or hardware workaround? did you have to make (m)any changes in VESC firmware to run with your board?

Hardware, basically above 80V the only way to get high accuracy in phase current sensing is to use a delta sigma modulator which output digital signals that can travel across isolation easily, but none of the MCUs with decent motor control provide support for sigma delta modulators. Ti and Silabs make ICs that have a delta sigma modulator, isolated transfer and a demodulator that converts it back into an analogue signal. Problem is both of them use differential analogue outputs, another feature not on motor control MCUs. Possibly you could have the ADC sample both outputs and calculate it in software but that means you must heavily customize software and means more work for the MCU. 

In the end the easiest solution was to have opamps convert the differential signal into a single ended 0-3.3V signal that most basic MCUs use.

[lizardmech]

I now have all the parts required to assemble an open EUC prototype. I have the modified vesc, mpu-6050 board and an arduino due. I have the mpu-6050 running with it's DSP sensor fusion in a demo so everything works. Now all I need is someone to help with coding. There's two ways it can be done, add the balancing code to the arduino MPU6050 demo and send it to the vesc via UART or modify one of the existing VESC control apps to read the mpu6050 via I2C. I more or less know how to make it work, I just someone to help write the code.

@electric_vehicle_lover @esaj either of you interested or able to work on it?

[electric_vehicle_lover]

I can help for sure but since you are not sharing your source files for the hardware, I will not collaborate with you. First share your source files as OpenSource and on Github like everyone does on OpenSource projects and then I will collaborate.

[esaj]

15 minutes ago, lizardmech said:

I now have all the parts required to assemble an open EUC prototype. I have the modified vesc, mpu-6050 board and an arduino due. I have the mpu-6050 running with it's DSP sensor fusion in a demo so everything works. Now all I need is someone to help with coding. There's two ways it can be done, add the balancing code to the arduino MPU6050 demo and send it to the vesc via UART or modify one of the existing VESC control apps to read the mpu6050 via I2C. I more or less know how to make it work, I just someone to help write the code.

@electric_vehicle_lover @esaj either of you interested or able to work on it?

Interested, but I need to get an Arduino Due or similar then, all my MCUs are 8-bit ATMegas (+ a few ESP8266's, but haven't familiarized myself with those yet). 

[lizardmech]

17 minutes ago, electric_vehicle_lover said:

I can help for sure but since you are not sharing your source files for the hardware, I will not collaborate with you. First share your source files as OpenSource and on Github like everyone does on OpenSource projects and then I will collaborate.

What do you want me to release? I only have one rough hand built prototype and the vesc software only has four numbers changed in the code. You have been working with closed hardware from microworks for a year, now suddenly it's a problem? I can upload the cad files but they are a total undocumented mess not suitable for release and wont work if assembled as in the schematics.

[lizardmech]

22 minutes ago, esaj said:

Interested, but I need to get an Arduino Due or similar then, all my MCUs are 8-bit ATMegas (+ a few ESP8266's, but haven't familiarized myself with those yet). 

I don't think you need the hardware.

I'm just running this generic demo on the arduino

https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050

all that would need to be done is port it across to c code and add controls for balancing

The VESC firmware has little self contained control applications

https://github.com/vedderb/bldc/tree/master/applications

If you look at app_nunchuk it's already a simple program that uses I2C for control. A few things would need to be done, init the mpu6050 and tell it to use it's internal sensor fusion DSP. Then run either a PID or active disturbance rejection algo to control motor current based on pitch.

Alternatively it can be ran on an arduino or other MCU and sent to the vesc via its UART app.

Someone made something similar but it's quite basic, doesn't seem to leverage the IMU DSP and uses a kalman filter + PID loop

https://github.com/Pixid-Design/VESC-OneWheel

[esaj]

2 minutes ago, lizardmech said:

I don't think you need the hardware.

I'm just running this generic demo on the arduino

https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050

all that would need to be done is port it across to c code and add controls for balancing

I used that same library with an Arduino Uno for the self-balanced robot with a PID-control running the motors with PWM. The PID-values of course needed to be set by hand (I used three potentiometers attached to the analog-pins):

 

 

2 minutes ago, lizardmech said:

The VESC firmware has little self contained control applications

https://github.com/vedderb/bldc/tree/master/applications

If you look at app_nunchuk it's already a simple program that uses I2C for control. A few things would need to be done, init the mpu6050 and tell it to use it's internal sensor fusion DSP. Then run either a PID or active disturbance rejection algo to control motor current based on pitch.

I'll try to take a look when I have the time (currently working, or at least supposed to ). AFAIK, the library already supports using the internal DSP for sensor fusion.

 

2 minutes ago, lizardmech said:

Alternatively it can be ran on an arduino or other MCU and sent to the vesc via its UART app.

Someone made something similar but it's quite basic, doesn't seem to leverage the IMU DSP and uses a kalman filter + PID loop

https://github.com/Pixid-Design/VESC-OneWheel

I'll take a look on that too, thanks for the link.

 

[electric_vehicle_lover]

23 minutes ago, lizardmech said:

What do you want me to release? I only have one rough hand built prototype and the vesc software only has four numbers changed in the code. You have been working with closed hardware from microworks for a year, now suddenly it's a problem? I can upload the cad files but they are a total undocumented mess not suitable for release and wont work if assembled as in the schematics.

I have been done, everything in OpenSource since the begin:

1. 3D Printed shell: https://github.com/EGG-electric-unicycle/shell
2. Simplified schematic and documentation from 30B4 board from MicroWorks: https://github.com/EGG-electric-unicycle/electronics-gen2_boards/
3. Firmware: https://github.com/EGG-electric-unicycle/firmware-gen2_boards
4. Android app (my girlfirend project were I also help): https://github.com/EGG-electric-unicycle/egg_app

For the boards you prototyped and firmware, you didn't released anything.

Edited October 24, 2016 by electric_vehicle_lover

[lizardmech]

1 hour ago, electric_vehicle_lover said:

For the boards you prototyped and firmware, you didn't released anything.

I still don't understand, the boards I didn't release were failures and the design was scrapped. Some of them literally catch on fire, it's kind of reckless to upload a design that doesn't work and is dangerous. It runs stock vesc firmware, all that is modified are the configurations in the config file. The entire point of the thing was to make it compatible to avoid having to fork the software. I can post the kicad files for the working prototype but it's out of date and lacks all the modifications I made while testing it the last few weeks.