Firmware

[Restless]

Even risking to get a bit off topic, why do u want to use an F4 or F7?

The STM32F103 is way more powerfull in the STM32F103Rx or Vx series than necessary for this application with a lot more features  

with 256kb+ (maybe 512kb or to be sure 1MB) Flash its the perfect choice.

 

Another reason why everyone uses the STM32F103 series is that they are designed for Motor Controll etc.

 

But i agree to every other of your points

[electric_vehicle_lover]

Cheap generics costs about 270€ -- and they are very good for starters and young/kids.
2nd gen cheap generics that go for 30km/h (like GotWay MCM4) costs more than 500€.

I also want to go for 30km/h. I will probably go with a generic instead of a brand like NineBot. I want cheap hardware that will mean that many people use, will be much more available, (accessible). Then we can make OpenSource firmware and apps for that hardware.
I prefer cheap than high end. For example, the success of Arduino!! Or RaspberryPI that we can now buy the new one for only 5€. I think the low price is (also) important for the success.

But I also like high end technology ;-)

Edited December 15, 2015 by electric_vehicle_lover

[Mystamo]

Hold the phone here guys,

Looks like a lot of good ideas and suggestions. I would recommend we get a good grasp of what is currently available. There is already a world of information on e-bike forums to take on here. No point in doing the work twice.

Increasing the power capabilities of any design would just mean switching out the FETS for more powerful ones. IRFB4110 was a popular choice for bikers back then but I think there are cheaper better alternatives available now. On e-bike controllers users were able to program their controllers using a UART programming interface. The firmware allowed the user to select their own limits which led to some crazy wild ebike burn outs and consequently some burnt motors and controllers. Some users managed to keep to reasonable currents for their equipment and enjoyed unrestricted ebike current fun.

As I mentioned before. The GEN 1 hardware is obsolete and overly non-intuitive. New typologies are both easy to program and understand. We should start with some custom boards that are design locally and have a PCB house cut the boards and put them together.

I'm about 75% of the way to reverse engineering the GEN2 boards. Maybe then we can talk about droping an STM32 with some more flash in there and adding some USB/LCD/WIFI/BLUETOOTH/GPS/ETC...

I hope to finish the reverse engineering work tonight and I'll start digitizing the content into Eagle by weeks end. At this rate I figure I should have some bare boards ready to assemble by next week.

Attached is my current progress on GEN2 PCBa.

 

Regards,

 

Mo

doc07860920151215163237.pdf

[Restless]

Just to stay on topic  

Since its Christmas time there are a lot of company parties these days. But ill be able to do some work tomorrow.

Ill focus on read inputs to actually Get something done and archive some progress here.

Im always open for New ideas but we should stay to our first goal: improve generic euc and then head for open source boards and many more features  

Anyways even for improvements and New features the f1 series is powerfull enough if we have enough flash to play with! We should probably replace it with one that has more Pins for more options and add some flash but at the Moment im sure its fast enough and provides enough power for a lot of extensions and features.

[electric_vehicle_lover]

@Mystamo I would suggest for you to create a new thread just about OpenSource electronics. This way we could keep this one just for firmware. I also hope that you can use the same github, maybe creating a new repo like "electronics-open_source" or something.
I know a bit well the RepRap project, of OpenSource 3D printers. They separate the printer in parts like: mechanics, electronics, firmware and software. I think this is due to the fact there is different developers for each part.
And believe, there is a very well know OpenSource firmware that is so famous that kind defines the standards interface between the firmware and software - it's Marlin firmware: http://reprap.org/wiki/Marlin
The same happens for OpenSource electronics, right now the most famous are the ones that uses AVR 8 bits/Arduino but there are others using Cortex-M3 or M4.
The same for the softwares, etc...
I also know Rockbox firmware, OpenSource for digital audio players, that have now 13 years old: https://en.wikipedia.org/wiki/Rockbox
This one is only for commercial available hardware... and I dreamed and tried to make an OpenSource hardware/player for this advanced firmware - no business model, no project :-)

 @Restless I already have working code to read inputs and I will push today. Turns out that I were trying to read the pin of PS_SIGNAL before config that pin as input :-)

Edited December 15, 2015 by electric_vehicle_lover

[electric_vehicle_lover]

I pushed my code. I added DEFINES for the pins.

Right now the PWM pins (H side of the bridge) aren't working -- I guess is something about config of the PWM.
When we have the PWM working, we will have the BLDC commutation ready to test. The hall sensors are also working. The other thing missing is reading the current signal. We need to simulate and know the value we should multiply/divide the voltage on ADC pin, to have the current value. We will limit the PWM duty-cycle when the current is over a specified value.

[Restless]

@electric_vehicle_lover Oh thats disapointing (that i was not able to find that out ) but awesome

I guess i have to set up Eclipse to make everything a bit easier for me.

 

[jayjay23]

Short update in MPU code, last weekend I tried to get that running and I believe it's connecting (getting one ID byte from the I2C), but the raw data can't be read, so still need to dive into this. (I tried with polling mode first, to keep it simple, if that works and makes sense in the context of the program flow, we can switch to DMA)

 

I changed the systick back to 10ms and implemented a delay function (needs rework though), what should be our goal for the systick, now it's 10ms, it was 1ms?

[lizardmech]

16 hours ago, Restless said:

Even risking to get a bit off topic, why do u want to use an F4 or F7?

The STM32F103 is way more powerfull in the STM32F103Rx or Vx series than necessary for this application with a lot more features  

with 256kb+ (maybe 512kb or to be sure 1MB) Flash its the perfect choice.

 

Another reason why everyone uses the STM32F103 series is that they are designed for Motor Controll etc.

 

But i agree to every other of your points

I want plenty of room for further development.

Even now without starting, I thought of many features I would like in the future. Weight sensors in the pedals to calculate max speed based on rider weight and battery remaining and to prevent run away wheels. Variable throttle responses based on roll angle of the wheel and RPM. Motion sensors on the bottom so I can add TCS and ABS. Proper battery level with estimated remaining range based on battery capacity and weight. 

[electric_vehicle_lover]

28 minutes ago, lizardmech said:

I want plenty of room for further development.

Even now without starting, I thought of many features I would like in the future. Weight sensors in the pedals to calculate max speed based on rider weight and battery remaining and to prevent run away wheels. Variable throttle responses based on roll angle of the wheel and RPM. Motion sensors on the bottom so I can add TCS and ABS. Proper battery level with estimated remaining range based on battery capacity and weight. 

That's why I like the "chinese" :-) -- they have a generic that works and is simple and cheap as possible. Is good for starters but then the starts will want more... maybe a Tesla Model S :-)

@jayjay23 1ms seems ok. If that interruption code takes about 1000 cycles, it will be 1000 taken from 64000 cycles (1ms = 64000 cycles).

[Restless]

3 minutes ago, lizardmech said:

I want plenty of room for further development.

Even now without starting, I thought of many features I would like in the future. Weight sensors in the pedals to calculate max speed based on rider weight and battery remaining and to prevent run away wheels. Variable throttle responses based on roll angle of the wheel and RPM. Motion sensors on the bottom so I can add TCS and ABS. Proper battery level with estimated remaining range based on battery capacity and weight. 

These things are pretty easy to achieve even with an atmega2560 .... limited by 256kb flash, 16Mhz & 8bit Structure 

How do i know? Take a look at Multicopters (yeah i know its a different use case, but they do pretty similar and a lot more stuff than our EUC boards).
They are able to hold balance by constantly calculating pitch, yaw, etc. etc. Using MPU6050, Baro, GPS, Controlling LEDS, Controll a Gimbal
Are able to fly completly autonom with Waypoints etc., Show informations on a Display
Have air-speed sensors and some even use Sonar for Distance messuring to improve the autonom landing feature.

Everything on a Controller thats so weak compared to our 32Bit "monster". 

The STM32F1 with 64kb is ok for normal use but not what you want, i agree. With 512kb or 1Mb and 100Pins, everything you want and even a lot more features would be an easy task for the ARM.

Does someone know the exact Load during driving a EUC with an STM32F1. For the case i described above its around 10-20% max. 

 

But i guess its a war of opinions  

 

Anyway:

I really love the idea of an improved design and an Upgraded Specs Controller board.
Maybe you should make a thread for OpenSource Hardware, guess it would be a better place for our conversation

[lizardmech]

2 hours ago, Restless said:

 

Does someone know the exact Load during driving a EUC with an STM32F1. For the case i described above its around 10-20% max. 

 

 

I'm not sure how much headroom STM32F1 has, I was looking at another opensource BLDC project that used an F4, someone asked if he could make an F1 variant and he said not without cutting some features. He has chibiOS running though not just motor code, it was pretty impressive, you can plug it into a linux machine and it has a full GUI for BLDC configuration.

[Restless]

@electric_vehicle_lover any guess why the PWM isn't working right now?

 

 

[electric_vehicle_lover]

@Restless I don't know yet :-(

The TIMER1 must be working. The Timer1 Counter register is at address: 0x40012C24 (I did correctly the math for this address??).

Using the memory browser on Eclipse I can't see that address with changing value... (I did this on another projects and it is great to found the if the counters are working or not).

Do you have any ideas??

[electric_vehicle_lover]

I believe I found the issue with TIMER1 and PWM.

Incorrect line: RCC_APB1PeriphClockCmd(RCC_APB2Periph_TIM1, ENABLE);

Should be correct: RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM1, ENABLE);
That's why I did saw the TIMER1 regs all at 0.

I will try this later today.

NOTE: And the  0x40012C24 is correct for the address of TIMER1 counter.

 

[electric_vehicle_lover]

We now have PWMs :-) I push the code.

Next will be the current and voltage measures.

[electric_vehicle_lover]

I just tried to motor (using the hall sensors). It don't start but have high current/short and the power supply protection makes his work ;-)
At least I can turn the motor by hand and see that is kind of blocked (also the current goes lower when it moves - I think that the commutation table is wrong but is a question to go and play with the possibilities), as I expected.

I really need to verify of the signals are correct for the bridge. Also very important is the current measurement.

[electric_vehicle_lover]

I don't have a power resistor right now to be able to measure the circuit amplification for current measure. I decided to look on the circuit and is very simple!!

So there are 2 signals about the current. One have an amplification of 11x and goes the an ADC. The other, well, I believe is like an ON/OFF comparator and goes to pin TIMER1 BREAK signal (I call to this signal MAX current).

I used the break signal for disable the motor, on the electric bicycle controller. When user pressed the brakes, the brake signal got active and the motor then moves free (because the bridge signals get off!!! This is very dangerous on an unicycle!!! I just can imagine this as a protection for when the motor is in short circuit/blocked for some reason.

My question right now is that the power resistors have a label of R007. That means the total resistance of both in parallel should be 0.0035 ohms. With this value, the 11x amplification and the transistor current MAX signal seem to not make logic... can someone verify??

EDIT:

Here is the code and calcs to get the current value.

What do you guys think that could be the motor peak power?? For instance, 1.5x the nominal value??

unsigned int motor_get_current (void)
{
  unsigned int adc_current;
  unsigned int current;

  adc_current = adc_get_current_value ();

  /*
   * 1A = 0.0385V
   * (350W nominal motor power) 5.8A = 0.2233V
   * (350*1.5 W peak motor power ??) = 0.335V
   *
   * 12 bits ADC; 4096 steps
   * 3.3V / 4096 = 0.0008
   *
   */
   current = adc_current * 0.0008;

   return current;
}
 

Edited December 17, 2015 by electric_vehicle_lover

[OliverH]

Got my regulated power supply yesterday and have all to start but still no motor. Would be a MSuper motor also usable for tests?

A general question: What about a commercial usage if we integrate functions to get a safety reliable EU (=> type approval)?

[electric_vehicle_lover]

@OliverH I think you can try use that motor. You can also open it and compare the internals with the generic motor: https://github.com/generic-electric-unicycle/documentation/wiki/Motor

About commercial usage, I think the ones that are interested, should worry about it :-)

About the ongoing development, I just got 2 mosfets in short-circuit. The power supply were protecting and eventually the system were to much time in "short-circuit" until the mosfets died. I will need to replace them and implement the current protection on the code. When the board were working, I could measure the current signal and I measured peaks of about 18 amps... -- I will make the code to cut at for example 3 amps t avoid the dead of mosfets.

[electric_vehicle_lover]

Added code for OVER current and MAX current protection.
Also started code for a state_machine.

OVER current is the signal on TIM1_BREAK pin. I assume that if we get there, then motor is in short circuit, motor power should be disable and the system blocks with buzzer on.

MAX current, the ADC measures the current signal and have a kind of internal comparator (analog watchdog) that turn on an interrupt if the current is over or under certain values predefined. On that interrupt, we compare the current and or turn off or turn on the PWM signal. This way, if the current is to much we turn off and when it lowers to much we turn on -- it should regulate the current for the specified value.

I didn't tested yet this code but I took as reference examples from STM32 and my old code that used the TIM1_BREAK pin. Can someone please keep looking at the code and/or test?? - is on github.

[jayjay23]

5 hours ago, OliverH said:

Would be a MSuper motor also usable for tests?

The motor interface is just the hall sensors, so if the operate at the same voltage than generic (which is likely) the other parameters are the order of the hall sensors and the number of coils per rotation, so maybe you can just figure that out and we make a define for both sets of parameters and could already support two motor types!

[Mystamo]

42 minutes ago, jayjay23 said:

The motor interface is just the hall sensors, so if the operate at the same voltage than generic (which is likely) the other parameters are the order of the hall sensors and the number of coils per rotation, so maybe you can just figure that out and we make a define for both sets of parameters and could already support two motor types!

#define

#ifdef

Where hashtags aka ampersand were used for writing code.. Not tweeting

 

[electric_vehicle_lover]

That's why OpenSource is so important!! -- on my development, I saw my board making smoke, literally and I were able to quick turn off thanks the power supply. One mosfet were in short-circuit. But also the circuit were in a short circuit even if the new mosfet were ok. After about 2h I found that R33 (from the next image) were burned and open circuit.

Using the osciloscope to compare the signals I could understand the gate of mosfet were at 2V while it should be at about 15V. I do not have the schematic for this controller but I followed the schematic from KU63 controller of electric bicycles and it seems to be equal :-) -- cheap chinese controlers ;-)

KU63 schematic is here as "OpenSource" from another user (Albert van Dalen) <3 !! http://www.avdweb.nl/Article_files/Solarbike/Motor-controller/China-BLDC-motor-controller-36V-250W.pdf
OpenSource is really important for us to be able to repair our own devices!! And I am learning a lot!! <3
http://www.avdweb.nl/solar-bike/electronics/ku63-motor-controller.html

Edited December 18, 2015 by electric_vehicle_lover

[electric_vehicle_lover]

Ok, I found why I was having burned mosfets. The LOW signals for the bridge are active low!! Code is no correct.

Then I verified for the first time the PWM signals. The frequency was 40khz but I lowered to 20khz (I used with success 20khz on my last project).

I also took some pictures of the signal at mosfet gate. Seems that the turn off is very slow, I think we will need to take care and use a good dead time value.

50% duty-cycle:

 

10% duty-cycle:

 

1% duty-cycle: