Firmware

[esaj]

4 hours ago, jayjay23 said:

This is my initial assumption, as I think that at the point were back EMF comes to the same voltage than the battery voltage the torque would be too less to keep you balanced, but this is just how I imagine it,'

The torque should apparently be zero when there's no voltage difference between back-EMF and the battery (there's no current flowing, and current is causing the torque)... not 100% sure on this though.

4 hours ago, jayjay23 said:

rotating a motor by hand (not fast) measuring two pins in AC mode (could be horrible wrong to do it) gives slightly above 10V (and shorting the PINs gives a  motor with a incredibly strong resistance, which I find really amazing).

From what I've read so far, shorting the motor with "itself" should pretty much slam it to stop (I suspect that's why people sometimes say they feel "resistance" when trying to turn the tire with their hands, if the bridge has broken so that the motor is shorted?). Here's a long, (probably) related response about a regenerative braking question which explains what happens in different situations (although it only uses a single half-bridge for 1-phase motor, but I think similar stuff is going on with 3-phase motor): http://electronics.stackexchange.com/a/56187

Edited November 15, 2015 by esaj

[Restless]

9 hours ago, esaj said:

The torque should apparently be zero when there's no voltage difference between back-EMF and the battery (there's no current flowing, and current is causing the torque)... not 100% sure on this though.

Thats completly right  But you'll not reach this point pretty often

The Link to regenerative braking is pretty interesting! Wasn't able to look inside my EUC yet, so i'm not sure if we just generate heat or get some energy back in the battery. Definitely something we could/should keep in mind if we develop our own controller later on.

[lizardmech]

Does anyone know what information is transmitted to the speed controller? I was looking at the robots people linked to but they use stepper motors so it's quite different to a 3 phase brushless motor.

From trying to observe how they work and looking at various control boards this is my guess.

The speed controller has 4 connections to the processor. PWM throttle, braking PWM, hall sensor RPM sent to CPU and a reverse motor switch.

I don't think the hall sensor is aware of which direction motor RPM is. So I think the code must have two profiles, a forward code, if the unit is at 0 RPM and forward tilt is detected it engages the forward movement code using forward angle for throttle intensity and backwards angle for brake intensity until it reaches 0 RPM again at which point the process finishes. If backwards tilt occurs the reversing process is started it's the same code however the reverse switch is activated on the speed controller and the relationship between tilt and throttle/brake is reversed.

The code should actually be very simple, I'm guessing it's nothing more than a blend of RPM and tilt angle. All we need to find is the ratio between speed and how much throttle is needed to tilt upright.

The most difficult part is the speed controller, the one on the generic EUC looks very weak and is likely only good enough for very weak motors and low speeds. For it to work we will need a highpowered 60v speed controller with hall sensor support and self calibration, inputs for throttle and braking, a reverse switch and RPM output to go back to the CPU.

I have been trying to find an off the shelf one without much success, but finding info on creating a custom one is difficult. Trying to add a calibration mode for the hall sensors confuses me the most.

 

Edited November 16, 2015 by lizardmech

[electric_vehicle_lover]

@lizardmech

Good discussion. I think generic UC boards have for speed control only the IMU.

About "I don't think the hall sensor is aware of which direction motor RPM is."
I am pretty sure hall sensors will say to us the direction of rotation. Please see my code here: https://github.com/casainho/EBike-Smart-Controller/blob/master/firmware/bldc.c

void commutate (void) <--- is called everytime there is a hall sensors signal change
get_current_sector (); <--- using a table, it looks for currents hall sensors signals and finds next commutation(related to hall sensors next sector)
If we want to rotate on the inverse direction, the table on get_current_sector (); should be inverted.

void commutate (void)
{
  volatile unsigned int sector;

  sector = get_current_sector ();

  switch (sector)
  {
    case 1:
    commutation_sector_1 ();
    break;

    case 2:
    commutation_sector_2 ();
    break;

    case 3:
    commutation_sector_3 ();
    break;

    case 4:
    commutation_sector_4 ();
    break;

    case 5:
    commutation_sector_5 ();
    break;

    case 6:
    commutation_sector_6 ();
    break;

    default:
    commutation_disable ();
    break;
  }
}

Maybe a good idea for a initial firmware is putting the motor running just in one direction and increasing the duty-cycle with increase of tilt.

Seems to the bottleneck for this project is now the lack of controller boards for the development and testing :-(

[esaj]

39 minutes ago, lizardmech said:

Does anyone know what information is transmitted to the speed controller? I was looking at the robots people linked to but they use stepper motors so it's quite different to a 3 phase brushless motor.

From trying to observe how they work and looking at various control boards this is my guess.

The speed controller has 4 connections to the processor. PWM throttle, braking PWM, hall sensor RPM sent to CPU and a reverse motor switch.

At least in most (if not all) cases, it would seem that there's no separate motor controller in the EUCs, but the main chip handles the motor control through the half-bridges as well as doing the measurements. Of course a separate motor controller could be used, just not sure if one is actually needed...

For an example of DIY-motor controller for an e-bike: https://endless-sphere.com/forums/download/file.php?id=158449  (the thread is here, but I haven't read it through, only glimpsed here and there: https://endless-sphere.com/forums/viewtopic.php?f=30&t=65297 )

You need at least 3 PWM outputs for controlling the high-sides of the half-bridges for each phase (or 6 if the low-sides are PWM-controlled too, although I seem to recall reading somewhere that there may not be need to use PWM with the low-sides, maybe simple outputs to open/close the low-sides could be enough, so like 0% and 100% duty-cycle with PWM). On top of those, input-wise there's 3 inputs for the hall-sensors, plus 3 inputs from current measurement. Also in that schematic, there's something called phase-feedbacks (back-EMF measurement?), so that's 3 inputs more.

 

39 minutes ago, lizardmech said:

I don't think the hall sensor is aware of which direction motor RPM is.

The direction cannot be distinguished with a single hall-sensor, but with two (unless they're exactly the opposite from each other?) or more, observing the order in which they trigger, you should be able to distinguish the rotation direction. As the 3-phase motors seem to usually have 3 hall-sensors, it's possible to measure both speed & direction (although some sources say that the hall-sensors cannot be used after the speed goes high enough, and then the speed should be measured using back-EMF from the floating phase during the transition of the low- & high-sides of the two other phases?).

 

39 minutes ago, lizardmech said:

So I think the code must have two profiles, a forward code, if the unit is at 0 RPM and forward tilt is detected it engages the forward movement code using forward angle for throttle intensity and backwards angle for brake intensity until it reaches 0 RPM again at which point the process finishes. If backwards tilt occurs the reversing process is started it's the same code however the reverse switch is activated on the speed controller and the relationship between tilt and throttle/brake is reversed.

The code should actually be very simple, I'm guessing it's nothing more than a blend of RPM and tilt angle. All we need to find is the ratio between speed and how much throttle is needed to tilt upright.

You can check ovaltineo's Segwayclone -source (which has defines for multiple different motor controllers/shields), it's a bit more complicated than that (with low-pass & complementary filtering for the gyro input, and then PID-loop for calculating the wanted change in speed): https://github.com/ovaltineo/SegwayClone

Here's a thread discussing it:  http://www.diyelectriccar.com/forums/showthread.php/ovaltines-segway-clone-89471p5.html

 

39 minutes ago, lizardmech said:

The most difficult part is the speed controller, the one on the generic EUC looks very weak and is likely only good enough for very weak motors and low speeds. For it to work we will need a highpowered 60v speed controller with hall sensor support and self calibration, inputs for throttle and braking, a reverse switch and RPM output to go back to the CPU.

I have been trying to find an off the shelf one without much success, but finding info on creating a custom one is difficult. Trying to add a calibration mode for the hall sensors confuses me the most.

I think I've seen multiple off-the-shelf -controllers when studying all the BLDC-stuff, but of course I don't have the links anymore, as I'm interested in building the controller myself with an Arduino and a bunch of mosfets & other components (for a 12V 3-phase BLDC, mind you, just for learning purposes )... Simply googling for something like 3-phase bldc motor controller should bring up a lot of links though.

[electric_vehicle_lover]

13 minutes ago, esaj said:

On top of those, input-wise there's 3 inputs for the hall-sensors, plus 3 inputs from current measurement. Also in that schematic, there's something called phase-feedbacks (back-EMF measurement?), so that's 3 inputs more.

On cheap generic UC controller board, there is only one 1 input for current measurement. I see the same on cheap KU63 e-bike motor controller: http://www.avdweb.nl/solar-bike/electronics/ku63-motor-controller.html

The inputs on the generic UC controller board:

/* Connections:
	*
	* PIN | IN/OUT| Function
	* ----------------------------------------------------------
	*
	* PA8 (TIM1_CH1) | out | Bridge_A-High
	* PA9 (TIM1_CH2) | out | Bridge_B-High
	* PA10 (TIM1_CH3) | out | Bridge_C-High
	* PB13 (TIM1_CH1N) | out | Bridge_A-Low
	* PB14 (TIM1_CH2N) | out | Bridge_B-Low
	* PB15 (TIM1_CH3N) | out | Bridge_C-Low
	*
	* PA2 (TIM2_CH3) | in | Hall_sensor_A
	* PA1 (TIM2_CH2) | in | Hall_sensor_B
	* PA0 (TIM2_CH1) | in | Hall_sensor_C
	* PA6 (ADC12_IN6) | in | BMF_signal-Yellow_A
	* PB0 (ADC12_IN8) | in | BMF_signal-Green_B
	* PB1 (ADC12_IN9) | in | BMF_signal-Blue_C
	*
	* PA7 (ADC12_IN7) | in | Current_signal
	*
	* PB6 (I2C1_SCL) | in/out| IMU_MPU6050-SCL
	* PB7 (I2C1_SDA) | in/out| IMU_MPU6050-SDA
	*
	* PA15 | out | LED_1-battery_indicator (active low)
	* PB4 | out | LED_2-battery_indicator (active low)
	* PB5 | out | LED_3-battery_indicator (active low)
	* PB8 | out | LED_4-battery_indicator (active low)
	* PB9 | out | LED-power_switcher (active low)
	*
	* PB3 | out | Buzzer(??)
	* PA4 | out | PS_signal(calibrate_wheel??)
	*
	*/

[lizardmech]

2 hours ago, electric_vehicle_lover said:

 

Maybe a good idea for a initial firmware is putting the motor running just in one direction and increasing the duty-cycle with increase of tilt.

Seems to the bottleneck for this project is now the lack of controller boards for the development and testing :-(

Would it be easier to start off with a small computer then move onto micro controllers once the software was more mature? You can get these for $35 usd, they have linux standard and realtime kernels, built in real time clock, GPIO. All you would need is a MPU6050 gyro breakout board and basic mosfet circuits to drive the motor.

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143703355573

http://flyduino.net/MPU6050-Break-Out-onboard-33V-reg_1

With the way ARM SoC prices are falling a microcontroller may not even be needed, just run linux and have a EUC specific IO board made that can run on any linux machine with a usb port.

[Restless]

11 minutes ago, lizardmech said:

Would it be easier to start off with a small computer then move onto micro controllers once the software was more mature? You can get these for $35 usd, they have linux standard and realtime kernels, built in real time clock, GPIO. All you would need is a MPU6050 gyro breakout board and basic mosfet circuits to drive the motor.

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143703355573

http://flyduino.net/MPU6050-Break-Out-onboard-33V-reg_1

With the way ARM SoC prices are falling a microcontroller may not even be needed, just run linux and have a EUC specific IO board made that can run on any linux machine with a usb port.

1. The core actually is pretty similar (not same) to the ARM running on the Odroid / Raspberry / BannanaPi etc. The STM32 running on the board we selected as our DEV Board is an 32bit ARM Cortex SoC, its powerful and should have more than enough reserves even for more complex tasks. You could probably write an auto pilot with way points or whatever (that would be pretty useless but hey  ).

2. You get a bigger overhead from using Linux with functions u don't use need etc. Even with a good RTOS Linux env. this task is not as easy as it sounds like. Specially when it comes to time critical tasks. Sure a RTOS should be able to handle this. But there is no need for using a whole LinuxOS running a C program with a lot of stuff we don't use. Instead of writing a C Program running "nativly".

3. The Dev boards i'm about to order (as soon as i get a go from the seller) are ~12$ / each. No need for extra MPU board neither a mosfet board to drive the motor.

 

The first step and goal is to develope an OpenSource Firmware that is maybe/probably/hopefully compatible to most EUC Controllers. We can't achieve that with a complete different board.

 

Thats just my opinion  i cant speak for the other devs

 

@electric_vehicle_lover i wrote them with the final order on Friday. I'm expecting an answer soon.

 

Kai

[electric_vehicle_lover]

I totally agree with @Restless on this questions about using another board running Linux or something. The developers "chinese" are very good in having something that is simple and cheap. The STM32F103 have specific functionalities for BLDC motor control - they did a great decision to use it!! The firmware get's much more simple with this specific functionalities.

Even using cheap "chinese" development tools, each of us developers may need to invest at least:

- generic EUC: 350€
- bench power supply: 150€
- oscilloscope: 350€
- controller board: 25€
- programmer/debugger: 20€
- rework air station: 200€
TOTAL: ~1100€ in materials

Let's keep this project cheap and simple :-)

[DebboR]

Just a thought:

Has anyone tried just contacting the manufacturers from these controllers (e.g. Microworks) to see if, maybe with a bit of persuading, they can provide some schematics / code for their controller?

I have ordered a 30km/h upgrade from Microworks recently, and they seem to be really friendly and helpful. It will be a slim chance, but we might as well just try, right?

[OliverH]

3 minutes ago, DebboR said:

Just a thought:

Has anyone tried just contacting the manufacturers from these controllers (e.g. Microworks) to see if, maybe with a bit of persuading, they can provide some schematics / code for their controller?

I have ordered a 30km/h upgrade from Microworks recently, and they seem to be really friendly and helpful. It will be a slim chance, but we might as well just try, right?

Yes. Forget about. Development must move to western countries to push our hobby ahead.

[Restless]

11 minutes ago, DebboR said:

Just a thought:

Has anyone tried just contacting the manufacturers from these controllers (e.g. Microworks) to see if, maybe with a bit of persuading, they can provide some schematics / code for their controller?

I have ordered a 30km/h upgrade from Microworks recently, and they seem to be really friendly and helpful. It will be a slim chance, but we might as well just try, right?

haven't seen this seller before, looks quiete nice though.

 

found one on Aliexpress: Sadly its not in stock atm :/ could be an alternative to the alibaba seller.

http://www.aliexpress.com/store/product/Factory-price-electric-self-balancing-unicycle-mainboard-one-wheel-scooter-PCBA-controller-DIY-balancing-car-accessories/513039_2034551122.html

[DebboR]

1 minute ago, Restless said:

haven't seen this seller before, looks quiete nice though.

 

found one on Aliexpress: Sadly its not in stock atm :/ could be an alternative to the alibaba seller.

http://www.aliexpress.com/store/product/Factory-price-electric-self-balancing-unicycle-mainboard-one-wheel-scooter-PCBA-controller-DIY-balancing-car-accessories/513039_2034551122.html

You have to mail them, they only produce them in small quantities. Mine took about 10 days to be manufactured. The only downside with this is that for the 30km/h, you also need to upgrade to a 500W motor (which they also sell). They ship with DHL Express. Mine should be here in a few days, so I can't wait to test it out ;-)

[Restless]

its not neccessary for me to reach 30km/h (i'm still learning, i dont wanna faceplant ... :D ), would be nice though. but a seller from aliexpress is most of the time faster with shippment, thats why

[lizardmech]

10 hours ago, DebboR said:

Just a thought:

Has anyone tried just contacting the manufacturers from these controllers (e.g. Microworks) to see if, maybe with a bit of persuading, they can provide some schematics / code for their controller?

I have ordered a 30km/h upgrade from Microworks recently, and they seem to be really friendly and helpful. It will be a slim chance, but we might as well just try, right?

This would be a good idea. Is there a list of known manufacturers for these boards? We can contact them and ask if they can supply a board with firmware source. Even if you had to offer them $500-$1000 it would be cheaper than buying equipment, split among a group of people it wouldn't cost much.

[electric_vehicle_lover]

@jayjay23 I updated the firmware with the firmware I used before and worked. Please test the flash LED code. Thanks.

Can someone please review the code to see if there is possible problems??
https://github.com/generic-electric-unicycle/firmware

[lizardmech]

I found a few other options.

Mpu6050 boards are only $5 on amazon

http://www.amazon.com/MPU-6050-6DOF-Gyroscope-Accelerometer-Module/dp/B00COD97LY

STM32 dev board $12

http://www.digikey.com.au/product-detail/en/NUCLEO-F401RE/497-14360-ND/4695525

BLDC controller $26

http://www.digikey.com.au/product-detail/en/EVAL6235N/497-4935-ND/725090

You would need to build a basic mosfet circuit for the high powered motor but that's very basic. It's a little more expensive but you get USB, debugging, labeled pins and you can change between different ST microprocessors easily.

[esaj]

33 minutes ago, lizardmech said:

I found a few other options.

Mpu6050 boards are only $5 on amazon

http://www.amazon.com/MPU-6050-6DOF-Gyroscope-Accelerometer-Module/dp/B00COD97LY

I ordered 2 lots (each lot containing 2 boards, so 4 MPU-6050's in total) of those boards from Aliexpress, at 4.63EUR (around 4.94USD) per lot, so 2.315EUR / 2.47USD per piece with free shipping:

http://www.aliexpress.com/item/High-Quality-2pcs-lot-6DOF-MPU-6050-Accelerometer-Gyroscope-3-Axis-Gyro-Module-3-3V-5V/32245746568.html

Got a bit carried away, I think I have something like 26 or 27 orders coming in from China, with some of them containing multiple items... 

[electric_vehicle_lover]

Oh men, I just deleted the wiki latest changes I did. For some reason, the repo of the wiki seems to work in a different way of the others and I did some mistake. The changes I did before were only on the web version and I lost when I did a git pull and after a git push -f. I had to make some changes to the repos because I commited with incorrect name and e-mail. I had to do git push -f and it worked perfectly on the other repos.

[Restless]

@electric_vehicle_lover

the best and safest way to work with git. Never push to master branch directly.

Always create a new branch.

 

If u want to change something:

1. checkout master

2. git pull

3. create new branch

4. modify add delete whatever u want

5. push

6. Create a merge request on github (that makes it also easier to review your changes)

 

7. merge to master. close and delete branch

 

@esaj are u going to order an STM-Dev Board too or do u want the MPU-Boards for something else?

Everytime i want something from Aliexpress i end up like you  the only down side is that it takes easily 15-20 work days for delivery. Thats the reason why i like to buy stuff from banggood.com and as shippment Priority Direct Mail (its about 0,50 - 3.00$ per shopping cart). Deliverytime is about 5-7 Work days, they ship the parcels over Netherland so its already in the EU so no problems with Customs even above 150$  

Edited November 17, 2015 by Restless

[esaj]

9 minutes ago, Restless said:

 

@esaj are u going to order an STM-Dev Board too or do u want the MPU-Boards for something else?

Everytime i want something from Aliexpress i end up like you  the only down side is that it takes easily 15-20 work days for delivery. Thats the reason why i like to buy stuff from banggood.com and as shippment Priority Direct Mail (its about 0,50 - 3.00$ per shopping cart). Deliverytime is about 5-7 Work days, they ship the parcels over Netherland so its already in the EU so no problems with Customs even above 150$  

I'm going with Arduino Unos (or probably they are copies of them) for now, once I get all the parts... The <32kb (there's some space used for the bootloader) flash size & somewhat low (16MHz) clock frequency may become problematic at some point, but should get me going with some basic stuff. Maybe I'll "upgrade" to STM's at some point, but Arduino seemed the easiest way to go for now.

My first plans are to try to build a small self-balancing 2-wheeled robot (with stepper motors), and maybe later on turning it into remotely controlled (either over Bluetooth or RF-transceivers), and "on the side", building a 3-phase BLDC-controller over mosfet-bridges for small 12V 3-phase motors I ordered. Then, if I get them both working, try to combine them into a self-balancing robot with 3-phase motors. It's more just about learning about motor control & self-balancing. But, I ordered lots of other stuff too (like different kinds of sensors) and have 5 Uno-boards coming in with the rest of the stuff, so who knows what I'll end up building (and how many boards / components I destroy in the process, that's why I ordered more than I think I need ). So not going for building an entire EUC -firmware for now

[Restless]

@esaj sounds nice  

that reminds me of something, instead of using BT or RF we could also use an ESP8266 for monitoring / communication to / from the controller board.

The ESP8266 is a fully programmable Wifi-Board. Its like an Arduino UNO just 32Bit based, 40Mhz and more flash  The NodeMCU version could also be interesting for you (all GPIOS are easily accessible) .

 

Back to the topic, with the 01 Version we could build an serial connection, instead of an harder to develop android/iphone app, we could run a web-server on the ESP8266 (no additional hw required) with an interface like an app (guess for me, it would be the easiest part to develop) 

[electric_vehicle_lover]

Please stay on the topic (create a new message for other boards firmware).

For this firmware, please write suggestions on the issue tracker: https://github.com/generic-electric-unicycle/firmware/issues

[jayjay23]

it's working nearly, but we have to agree on a common build environment.

So the result of my testing is that 2 LEDs are working, so we have some PIN problem still, the working LEDs are the two right most (of you have board in front of you with mosfets on the top), this is the PINs near to the PIN 1 corner.

The buzzer is silent. The timer tick is much slower, maybe around 4-5 seconds, so here is something to do also.

For the environment, I deleted my SPL as it was now double and the CAN file (which gave errors) from yours (I commited nothing), I finally used my old Makefile as it's handwritten and I understand it better. So it seems the problem was the linker file (and maybe something in SPL altough this should be really easy to try out).

Regarding the path to the arm gcc tool chain, I wonder why the path's differ between us, do you use linux or windows, well at least we need to find a way how we can work at this without changes, maybe a environment variable?

Which dev. environment do we want to use, or can we use each what we like, I see your makefile is auto generated, but if we can somehow manage it I would like to stay with mine too. You said you want to use eclipse, I can understand this as I like eclipse too, but I'm also a console guy, so currently I'm totally happy with how this works.

Do you have any ideas of how we can streamline this?

 

What I have to point out is something about the MOSFETs (it's not in the datasheet), a while ago I explained how ridiculous I found it that my cooling body had a stripe of battery isolation tape on it, I removed it. Always when I pass by the table I can't resist to turn the wheel in the vise  and I thought mmmh, it's harder, was that always. Now the solution to this is that the cooling body that was no directly attached to the backside of the MOSFETs indeed shorts them!!! And if you touch two of them while the power supply is on, you know roughly which voltage is there :-D. This is known to me from some devices, but I didn't expected it from the FETs as the cooling is quite essential and electric isolation always means worse temperature conduction (yes there are foils for both, but I guess they are more of a compromise than the ideal solution).

 

Here I post you the gdb session, as I'm really amazed that all this is working

gdblog.txt

 

When I have time, I can also look at the wiki as I have a state from 2 days ago, so I see at least some content that I could recover.

Edited November 19, 2015 by jayjay23

[DebboR]

2 minutes ago, jayjay23 said:

What I have to point out is something about the MOSFETs (it's not in the datasheet), a while ago I explained how ridiculous I found it that my cooling body had a stripe of battery isolation tape on it, I removed it. Always when I pass by the table I can't resist to turn the wheel in the vise  and I thought mmmh, it's harder, was that always. Now the solution to this is that the cooling body that was no directly attached to the backside of the MOSFETs indeed shorts them!!! And if you touch two of them while the power supply is on, you know roughly which voltage is there :-D. This is known to me from some devices, but I didn't expected it from the FETs as the cooling is quite essential and electric isolation always means worse temperature conduction (yes there are foils for both, but I guess they are more of a compromise than the ideal solution).

Are you sure it's normal tape? Usually, silpad is used to insulate the FET's from the heatsink. This is some kind of rubbery plastic that is very thermally conductive, but still a electrical isolator. To screw the FET's down, most of the time either a nylon screw is used, or isolated with a nylon bushing, to again prevent the short circuit you are talking about.