Firmware

[OliverH]

You've seen this doc from ST?

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/CD00298474.pdf

Edited November 11, 2015 by OliverH

[electric_vehicle_lover]

Yes I did but is something complex for me.
I am adding application notes to the Documentation github repo.

[jayjay23]

20 hours ago, electric_vehicle_lover said:

One thing I believe must be done and maybe you can help. Find the pin that measures the battery voltage and records the voltage pin value for battery voltage of:

Yes, this is exactly what I wanted to do, next days I don't have much time unfortunately now that that I have everything here. Actually I would like to go with the current source code which is first continue with the MPU6050 code and then look for the analog readings.

 

20 hours ago, electric_vehicle_lover said:

I think the EUC motors may have much more poles and so much more signal changes for each full rotation of the wheel and so the circuit of hall sensors must be faster.

Do you know the max frequency (RPM*poles) you achieved?

20 hours ago, electric_vehicle_lover said:

I think BEMF is a need after some speed, maybe because hall sensors are kind of slow. I don't think is a question of safety.

That's what all sources say, so it's surely right, I just have not yet seen the limits of the hall sensors.

 

 

6 hours ago, OliverH said:

You've seen this doc from ST?

Looks actually quite intersting, it brings up a ton of thing that we can consider cool features. Compexity is indeed one thing, can we get that running, beside

that what scares me is maybe the size this thing requires, it seems it can be boiled down but the result is a bit difficult to see, but we can have a look anyway.

[electric_vehicle_lover]

I just added the initial schematic: https://github.com/generic-electric-unicycle/electronics. I did draw the bridge part, including the current measurement and the pins information that @jayjay23 shared.

Next I want to draw the hall sensors connections and later start the firmware to make the motor running. Maybe at 20% duty cycle, without current limit verification (bench power supply save us here).

@jayjay23 you are the only of us that have a generic unicycle ready to receive firmware. Are you able to test a firmware to make the motor running?
Did you run any firmware on the board already? like to flash the battery state LEDS??

 

[electric_vehicle_lover]

I update right now the schematic with the hall sensors.
I also added/imported the first code to control the motor, from https://github.com/casainho/EBike-Smart-Controller/

@jayjay23 maybe I can work on a separated branch since you want to work on the IMU code?

[electric_vehicle_lover]

@jayjay23 thank you for researching and sharing the information regarding the STM32F pins connections and signals. I just used that to update the schematic that now have all the pin information you shared. Can you please give a look to see If I forgot something?? -- need to install KiCad (is available for the 3 OS):

https://github.com/generic-electric-unicycle/electronics/tree/master/generic_electric_unicycle

After having all the pin connections connections on the schematic, now I want to update the gpio.c file with a table for each pin function and do the firmware to configure each one.
I think the very first code can be some blink (using the SysTick interrupt) sequence for the battery indicator LEDs :-)

Edited November 12, 2015 by electric_vehicle_lover

[electric_vehicle_lover]

Just updated the pin table documentation on the firmware file gpio.c:

/* 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
 * PB4                 | out    | LED_2-battery_indicator
 * PB5                 | out    | LED_3-battery_indicator
 * PB8                 | out    | LED_4-battery_indicator
 * PB9                 | out    | LED-power_switcher
 *
 * PB3                 | out    | Buzzer(??)
 * PA4                 | out    | PS_signal(calibrate_wheel??)
 *
 */
 

[jayjay23]

16 hours ago, electric_vehicle_lover said:

 you are the only of us that have a generic unicycle ready to receive firmware. Are you able to test a firmware to make the motor running?
Did you run any firmware on the board already? like to flash the battery state LEDS??

A complete unicycle is not completely right, but the controller and the motor  (so I have to improvise on LEDs and power switch), but still I can use this for testing sure!!

So far I followed a simple Hello World command line example that shows mainly how building works and how to debug, this created a firmware file with a simple for loop incrementing a counter which I could follow using gdb, so yes this basic stuff is working.

If you want to try the LEDs I have to solder some, you can also try the buzzer which is onboard.

[electric_vehicle_lover]

Ok, now I remember that you changed the motor and the controller of your unicycle.

If you want, you can go ahead with current firmware, configure the pin output for the buzzer and do some intermittent sound using the Systick interrut. 

Do you have an oscilloscope for using on this project??

[jayjay23]

I soldered the LEDs and a switch, so now it could be put on (I know this vise will hold nothing in case!, I will switch to something more solid):

Unfortunately less time these days to try out more, this weekend is already fully planned.

[Restless]

Hey Guys

 

First of all, i like that there is already quiete some progress here

Today i got a reply for my inquiry.

 

Its about 150$ in total.

That means incl. german tax ~180$

So we have 10 Boards thats around 18$ each

That should be around 16,70€ / 17€

 

I dont know how heavy these boards are. I would prefer if u would choose the last option. ;)

Shipping in to my german fellas:

3,79€ - 1 kg (max. 30 x 30 x 15cm) - No Tracking

4,29€ - 2 kg (max. 60 x 30 x 15cm) - No Tracking

4,99€ - Paket < 2 kg (max. 60 x 30 x 15cm) - Tracking

 

For Portugal, thats up to you to choose or if it doesn't fit in the first one i have to choose the second option for you

small box up to 2 kg (max. L+B+H=90 cm) - 8,79€ + 2,20€ (for Tracking)

Paket up to 2 kg (max. 60 x 30 x 15cm) - 13,99 incl. Tracking

 

That would be:

@OliverH 3 boards (51€ + [4,99€ shipping]) = ~56€
@jayjay23 3 boards (51€ + [4,99€ shipping]) = ~56€
@electric_vehicle_lover 2 boards (34€ + [10,99€ shipping]) = ~45€

Restless: 2 Boards (34€)

 

2x51€ + 2x34€ = ~180$ (depending on the exchange rate a bit more or less)

 

I would say (if u guys are fine with that), if i end up with a couple $ more than the total amount was, that i just donate it to a donation paypal account for this project.

 

btw. my Unicycle should arrive tomorrow

 

-----------------------------------------------------

 

Just as a sidenote.

I spoke with a friend of mine who is an electric engeneer and he was interested in this project. Not right now, since he is pretty bussy but maybe later on.

Not in programming a fw but maybe in design a opensource controller based on the same or similar ARM. And compatible to the one we wanna order.

 

Another Sidenote:

(might only be availiable in germany idk)

if someone still needs an Power Supply he told me to get this one, it has output: 2x 30V, 5A each OR if you go into combined mode its either: 1x 60V with 5A or 1x 30V with 10A

Modell: QJ3005EIII

http://www.amazon.de/Labornetzger%C3%A4t-regelbar-Digitalanzeige-QJ3005EIII-Einschaltstrombegrenzung/dp/B00BSP911A

 

 

wish u a great evening.

 

Kai

[electric_vehicle_lover]

I am trying to build the code but for some reason it do not build. An option is to use the makefile and the libs I were using on my old project -- let's see what I will get.

@jayjay23 nice to see your setup. I will share mine also later - we can take some ideas from the others :-)

@Restless good :-) -- it is perfect for me to have 2 boards for 45€. Please send me you paypal account so I can transfer to you. I really need the boards to be able to advance on this project.

Would be great if in future we could buy a board to upgrade our unicycles, an OpenSource board maybe by us. I can see the same happening with unicycles, that happened with hexacopters, 3D printers, etc.

Sidenote: I am still learning to ride my unicycle. Today I trained again and I feel I am near :-) :-)

Edited November 12, 2015 by electric_vehicle_lover

[electric_vehicle_lover]

@jayjay23 I couldn't build the code. I had to change the make file, just the path to the gcc and one line for the linker script. I tested with the gcc-arm-none-eabi-4_9-2015q2-20150609-linux and I even updated the README file with more information.

I hope is all ok. I will now start adding code. Maybe to use the buzzer or the LEDs.

[electric_vehicle_lover]

Ok, I just made the first code that should blink the battery LED indicators. Can someone please review the code?? -- here is the files:

- https://github.com/generic-electric-unicycle/firmware/blob/master/src/main.c
- https://github.com/generic-electric-unicycle/firmware/blob/master/src/gpio.c

@jayjay23 maybe you could build it, flash and try/debug ;-) :-)

[esaj]

Sorry for derailing this topic a bit, but I thought you guys would probably be among the people who know the answer...

I've been reading up on driving 3-phase BLDC-motors, and while the "basics" is pretty much clear (commutating, PWM, hall-sensors etc.), I was wondering how the unicycles deal with the battery voltage dropping. If the battery is more drained and drops to, say, 45V, but the wheel can still be ridden at full speed (high back-EMF), is the battery voltage somehow "boosted" (step-up transformer or something?) higher so the motor doesn't start regenerative braking (if the voltage from battery direction is below back-EMF), or are the motors only ever driven at so low RPM, that the back-EMF voltage stays at or below the "minimum allowed" battery voltage (45V) at all times?

[electric_vehicle_lover]

@esaj I don't have a clue. I hope to learn by doing and experimenting.

About regenerative braking, I am still to learn about it.
My electric car deactivates regen brake when the battery is full - usually when I leave my garage and the battery is fully charged, after about 3 kms of travel, the regen brake gets active.

[UKJ]

At the post above, elec vehi (can someone explain how to get blue highlighted like"@esaj" above please)

This makes total sense and seems easy to program into E U C, or is my extremely limited understanding missing something.

If the "brain of the system" senses that there is to much voltage it will shut down to protect over charging from REGEN, if they can do this with cars why not with E U Cs?

UKJ

[OliverH]

2 hours ago, UKJ said:

At the post above, elec vehi (can someone explain how to get blue highlighted like"@esaj" above please)

This makes total sense and seems easy to program into E U C, or is my extremely limited understanding missing something.

If the "brain of the system" senses that there is to much voltage it will shut down to protect over charging from REGEN, if they can do this with cars why not with E U Cs?

UKJ

Just type the @ and the username and select from the pop up list.

[UKJ]

Thanks @OliverH!

ukj

[jayjay23]

On 11/12/2015, 1:37:07, electric_vehicle_lover said:

maybe I can work on a separated branch since you want to work on the IMU code?

Yes sure, the only thing I'm unsure about as I don't know exactly how it can work is, that we may need to merge the initialisation stuff, but

this should be not a big problem anyway.

On 11/12/2015, 2:09:03, electric_vehicle_lover said:

Can you please give a look to see If I forgot something?? -- need to install KiCad

I need a bit more time for checking this out.

 

On 11/12/2015, 6:22:47, electric_vehicle_lover said:

Do you have an oscilloscope for using on this project??

Unfortunately not.

 

21 hours ago, Restless said:

@jayjay23 3 boards (51€ + [4,99€ shipping]) = ~56€

Just give me a note on how and when to transfer which amount (you can PN me about a email (and PGP)).

7 hours ago, esaj said:

I was wondering how the unicycles deal with the battery voltage dropping.

I needed to read bit more about that and only found a information in a another forum from somebody who seems to be sure about how it works. I was always convinced that back EMF has to be less than battery voltage as torque should get under a stable value way before back EMF reaches battery voltage, and the wheel should get instable way before reaching a torque of zero :-).

I first thought that it would be a phase shift issue, but actually the supply voltage is activated in the moment when the magnet is on it's way to the coil and this is also the moment where the back EMF field is largest as the induced field is largest when the magnetic field changes most, which is in the approach phase, when too far away or too near the change in the magnetic field is smaller.

Well the answer from this thread (http://www.microchip.com/forums/m431354.aspx) is more or less that there are boosting effects, but without any special circuit. If you think of how old combustion motors create the ignition spark (or maybe something similar is used in fluoresecence light starters if I'm not wrong), they use a coil (winding) like the ones on our motors (but maybe different number of windings :-)) loaded with 12V, and when the magnetic field collapses the resulting voltage can be much higher than the charging voltage. So it should work somehow like this I think.

8 hours ago, electric_vehicle_lover said:

maybe you could build it, flash and try/debug ;-) :-)

It's really a pity that I have no time these days (we are even not at home), if it's not too late on sunday maybe I can give it a chance, I'm really curious.

 

10 hours ago, electric_vehicle_lover said:

I couldn't build the code. I had to change the make file, just the path to the gcc and one line for the linker script

Once I have your code I can compare, if you let me know what your problems were we can go for the right way. I just choose the path to gcc be ../gcc/gcc-arm-none-eabi

relative to the repository root. I made 'gcc-arm-none-eabi' actually a link to the version I was using so I can switch that, but anyway this was just how I made it on my PC and I thought it could be repeated on other environments but I'm open to anything that we can use simultaneous.

[lizardmech]

I'm interested in this but I was thinking of a different approach.

Correct me if I'm wrong but these euc consist of a 32bit controller + solid state gyro (usually MPU6050), BMS for the battery and a a controller for the motor. The interesting thing is there's already a board with both these components and fully featured GPL software, they use them in quad copters.

Would it be worth splitting the EUC board into 3 sub components so they can be modified and upgraded individually? If you could fork cleanflight and set it up for EUC use all you would need is a BMS and speed controller and you have a working opensource EUC system ready to go. I'm not sure but some high end RC speed controllers controllers might even work, theres 2000w+ motors in some electric ducted fans planes.

Board example : http://www.readytoflyquads.com/the-flip32-deluxe-523

Possible software base http://cleanflight.com/

[Restless]

Hey Guys

 

to the orders, as soon as i get a reply from the seller ill pm u with bank account informations (bank or paypal is fine with me)

 

2 hours ago, lizardmech said:

I'm interested in this but I was thinking of a different approach.

Correct me if I'm wrong but these euc consist of a 32bit controller + solid state gyro (usually MPU6050), BMS for the battery and a a controller for the motor. The interesting thing is there's already a board with both these components and fully featured GPL software, they use them in quad copters.

Would it be worth splitting the EUC board into 3 sub components so they can be modified and upgraded individually? If you could fork cleanflight and set it up for EUC use all you would need is a BMS and speed controller and you have a working opensource EUC system ready to go. I'm not sure but some high end RC speed controllers controllers might even work, theres 2000w+ motors in some electric ducted fans planes.

Board example : http://www.readytoflyquads.com/the-flip32-deluxe-523

Possible software base http://cleanflight.com/

@lizardmech thats some thing we already thought about too, but there are some issues since its not a multicopter. The balancing / motor system works quite different and a big pro for our actual dev board decision is, there is everything ready to develope the firmware. There are some code snippets out there for balancing wheel problems, rewriting a firmware designed for a pretty different problem wouldn't be so much easier.

 

@everyone I asked the seller for a spec / datasheet, hopefully he can provide one. But i dont really think so

 

Kai

[esaj]

14 hours ago, jayjay23 said:

I needed to read bit more about that and only found a information in a another forum from somebody who seems to be sure about how it works. I was always convinced that back EMF has to be less than battery voltage as torque should get under a stable value way before back EMF reaches battery voltage, and the wheel should get instable way before reaching a torque of zero :-).

I first thought that it would be a phase shift issue, but actually the supply voltage is activated in the moment when the magnet is on it's way to the coil and this is also the moment where the back EMF field is largest as the induced field is largest when the magnetic field changes most, which is in the approach phase, when too far away or too near the change in the magnetic field is smaller.

Maybe I misunderstood your answer or the link (which talks about regenerative braking), but my question was not about regenerative braking...  Or did you mean that the back-EMF will be much smaller when the voltage from the battery direction is "turned on" and lower voltage than the "peak" back-EMF can still be used to drive the motor?

Let me rephrase with a simple example:

-A motor is running at a steady speed, producing a back-EMF of 60V

-After a while the the battery is drained and can only give out a voltage lower than 60V, say 58V

How can the mainboard then keep the speed steady, if the battery voltage is below the back-EMF? Wouldn't this cause the motor to start braking regeneratively (current is reversed), because the back-EMF is larger than the voltage from the batteries?

From my very limited understanding, either the battery voltage has to be boosted higher before the half bridges, so the motor "sees" 60V (well, actually a little more to overcome friction etc. to keep it running steadily) from the battery direction, or the motor RPM is always kept so low (even at the maximum speed of the wheel) that the back-EMF can never reach that high voltages, but instead at max speed is still below the "out-of-battery"-warning level of the mainboard (for example, 45V)?

If the rider tried to accelerate further, that shouldn't be even possible, because the voltage would probably dip even further due to higher current required during the acceleration, so probably the wheel would tilt forwards (as it cannot accelerate to correct the tilt caused by the rider). I know my Firewheel could be ridden at max speed even near the out-of-battery warning (which triggers around 47V), so that left me wondering how it's done.

I can't tell just by looking at the board if there's some sort of step-up going on, here's a picture of the board:  

 

[jayjay23]

On 11/14/2015, 12:45:22, esaj said:

Or did you mean that the back-EMF will be much smaller when the voltage from the battery

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, 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).

@electric_vehicle_lover: I just tried shortly the LED blinking code, but it seems to crash in the SysTick_Config() call:

 

(gdb) target remote :3333
Remote debugging using :3333
0x2000003a in ?? ()
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x2000003a in ?? ()

(gdb) bt
#0  0x2000003a in ?? ()
#1  0x0800018a in SysTick_Config (ticks=134227105) at src/spl/CMSIS/core_cm3.h:1699
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

 

The corrupt stack error maybe is a indication that something in the basic setup (linker script) is not yet correct, I have no clue here and basically copied from some examples,

if you have not taken these files from your project already I would try this next.

One comment for all who use a power supply, if not taken with care the regenerative breaking could maybe damage the power supply, at least this is what I read in some thread, though I had no problems when running my wheel free hand, so my impression is that for testing this should be no issue (the first code will not have that anyway).

[electric_vehicle_lover]

@lizardmech , thank you for your suggestion and links. I created a page on the wiki with links to other projects and a put that link there also :-)

https://github.com/generic-electric-unicycle/documentation/wiki/Links

I came from a project similar - making a controller for electric bicycles!! The chinese cheap and simple version use an unknown microcontroller that we couldn't use. Then we decided to make our own controller... it takes much more resources and so project no finished :-(

@jayjay23 , thank you for trying. I will then use the scripts I used before and that works. I also saw some script (link script I think) that ARE NOT OpenSource and so it is a good idea to use the ones I used before. I will do it!!

About the power supply, I am afraid to use it and the programmer/debugger. Because the ground loops  - since I understand, we will have the computer connected to AC and the power supply also to AC:

• Non-isolated power supplies.
  Most AC power supplies with 3-pronged plugs will short the MAINS earth ground pin to the power supply ground output. This include's your PC's ground. If your DUT is powered from a wall power supply, and your PC is also plugged in, this will form another ground path.
  Keep in mind, if you're using a laptop that's not plugged in, even an attached external monitor will create a ground loop.

I think one option is simple to disconnect/isolate the MAINS earth pin to the power supply mains connector.

Edited November 15, 2015 by electric_vehicle_lover