Firmware

[electric_vehicle_lover]

UUAAAUUUU!!! the motor now RUNS!!! Don't you believe?? see the video I registered :-)

Please note that it is forced to run, it does not use the hall sensors, instead, is forced the commutation every 25ms - the code is on github as always :-)

 

Edited December 19, 2015 by electric_vehicle_lover

[jayjay23]

@electric_vehicle_lover:

Wow, that's really great. Could you already make progress in the current measuring then or does it run just by duty cycle and hall sensors?

Did you use a second board then, if the other is damaged or could you repair it already?

[electric_vehicle_lover]

It runs with a fixed duty-cycle and fixed period. I may had luck with that combination :-) I will now take the opportunity to measure and understand the current circuit.

I repaired the board by exchanging 3 mosfets and one resistor.

[electric_vehicle_lover]

It runs with a fixed duty-cycle and fixed period. I may had luck with that combination :-) I will now take the opportunity to measure and understand the current circuit. Is very important to have the current protection working!!

I repaired the board by exchanging 3 mosfets and one resistor (sourcing from the other board).

It runs with a fixed duty-cycle and fixed period. I may had luck with that combination :-) I will now take the opportunity to measure and understand the current circuit. Is very important to have the current protection working!!

I repaired the board by exchanging 3 mosfets and one resistor (sourcing from the other board).

[electric_vehicle_lover]

I talked with Albert and thanked for his sharing of the KU63 controller schematic and so much information. He added a reference to our project on his page :-)

I really think that current controller is based on KU63 or similars.

[lizardmech]

I found someone selling the CAD files BoM and firmware for the generic airwheel 14" controller.

I can't quite tell if it includes uncompiled source or just a binary blob. I need to find someone who speaks chinese to try and ask him.

From what I can tell the file list is 1. CAD file 2. Binary ready to flash? 3. Unknown orange logo, is it source code? it's just named unicycle. 4. firmware flashing instructions. 5. BoM list in excel file.

[electric_vehicle_lover]

I think the firmware is just the binary file. Source files can be something like 100+ files. Also if they were selling the sources it would lost value... Also I think that the sellers just had access to copy the binary file and not the sources. Sources have much higher value because means that companies could improve while like that they just can make copies.

I think this reality shows why there is many EUCs using the same boards, microcontroller and the firmware behaves the same!!!

This companies may not have ReD department that can full develop all the system. An OpenSource firmware including board, app, will let the companies improve even more and costumize their products -- I think our project can be very relevant to EUC companies/market/users :-)

[lizardmech]

I think the orange one might be an .exe for flashing unless it's some weird project file archive for some old windows XP era program for programming embedded devices. It would be pretty easy to decompile a 64kb arm binary wouldn't it?

[electric_vehicle_lover]

Would take only 20 seconds as we already use the disassembler on our project.

I am not interested on that firmware as there is almost no value, since alternatively I can have much more knowledge and opportunity -- OpenSource means we can continue improve and have the power of knowledge. The best they did were to use STM32F103 :-)

[lizardmech]

It would save time just to have a look how they're using the MPU6050 and whatnot wouldn't it though?

[electric_vehicle_lover]

There are a some OpenSource projects that use MPU6050 - there is more value there with sources and comments and explanations that others share. There aren't nothing really different in this project compared with others.

[lizardmech]

11 minutes ago, electric_vehicle_lover said:

There are a some OpenSource projects that use MPU6050 - there is more value there with sources and comments and explanations that others share. There aren't nothing really different in this project compared with others.

What are some good open source projects to study MPU6050 and inverted pendulum balancing?

[electric_vehicle_lover]

There isn't a list of them on our wiki - please search on Google and if possible add the links you found to project wiki.

Edited December 20, 2015 by electric_vehicle_lover

[jayjay23]

Ok, after implementing a proper delay function (added a util.c for that) the MPU6050 raw data can be read and looks quite reasonable already!

I continued a little bit with the glue from raw to filter but need some more work on here.

[jayjay23]

Glue compiles now at least, but need to figure out why soft float stuff is not working.

[electric_vehicle_lover]

@jayjay23 good work!!

On void update_duty_cycle (unsigned int value) I also verified that a multiplication of a float gives problems!!

I have good news: the motor now work using hall sensors :-) :-)

Can you guys please pull the code and test??

Right now the code have a 5% duty-cycle. Please try also higher values on function void update_duty_cycle (unsigned int value).
With 5%, the motor runs at low speed and easy to block by hand. When blocked, it consumes 0.25A (about 0.05A per 1%; 100% would be 5A --> 300W).
There is no current control yet (the code is there but seems not working) and so limit the current with the power supply.

[jayjay23]

6 hours ago, electric_vehicle_lover said:

I have good news: the motor now work using hall sensors :-) :-)

Ok, cool, I think with that we can already soon build a firmware that is a bit rideable!

 

6 hours ago, electric_vehicle_lover said:

On void update_duty_cycle (unsigned int value) I also verified that a multiplication of a float gives problems!!

Which kind of problem? I stripped my problem down to passing a float as an parameter and doing nothing more, the code

when executed ends up in some exception handler, WWDG_IRQHandler(), I read about various options to the linker,

but maybe we are linking against the wrong libs, I also added libm.a and changed LD command to gcc as it does some

magic here to avoid undefined symbols from the system libraries.

 

[SlowMo]

Can you add to activate the left and right auto balance feature in the firmware?

[electric_vehicle_lover]

@jayjay23 I don't have a bicycle computer with me to measure the velocity of the wheel. Right now we could run at 80% duty-cycle or more and measure the motor/wheel velocity and find if is something much more then the 16km/h of the original firmware :-)

Maybe even trying steps of 10% and make a graph of velocity.

I will need to make the float mult again and see and report the error.

@SlowMo Sure, we are working to make a full feature firmware but even with more features like unlimited velocity when compared to original firmwares.

[esaj]

3 hours ago, jayjay23 said:

Ok, cool, I think with that we can already soon build a firmware that is a bit rideable!

 

Which kind of problem? I stripped my problem down to passing a float as an parameter and doing nothing more, the code

when executed ends up in some exception handler, WWDG_IRQHandler(), I read about various options to the linker,

but maybe we are linking against the wrong libs, I also added libm.a and changed LD command to gcc as it does some

magic here to avoid undefined symbols from the system libraries.

 

Not that I know anything about writing and linking code for ARMs, but could it be that the CPU either doesn't support floating point operations (" The ARM/thumb2 variants are very cost effective, and made by a number of manufacturers. I chose the STM32F103 series because it is tolerant of a wide supply voltage range, fits well into a jtag environment, and is easily available. The thumb2/Cortex processors support all 32 bit functions except hardware floating point") or that the hardware FPU isn't enabled (http://visualgdb.com/tutorials/arm/stm32/fpu/ but this talks about STM32F4 and using -mfloat-abi=hard to enable hardware floating points)? Maybe it needs a software floating point library?

Do other parts of the code use floats and still work?  The answer of this: http://stackoverflow.com/questions/27623885/stm32-wwdg-interrupt-firing-when-not-configured StackOverflow -question mentions that the interrupt handler being called may not necessarily be WWDG_IRQHandler, but something else, and it's being shown wrong because of compiler optimizing shared code:  

Another while(1); may be sharing that code due to optimization. Does the map file show only the WWDG at that address ?

 I was able to figure out that the HardFault_Handler was what was actually being called.

Just my two cents, I could be in completely wrong track here...

[electric_vehicle_lover]

I added interface to define motor rotation direction:

  motor_set_duty_cycle (50); // 50 --> 5%
  motor_set_direction (RIGHT);
  motor_start ();

Next I want to work on the MAX current control. After, work on the braking/regeneration - I don't know nothing about this subject.

[jayjay23]

6 hours ago, esaj said:

but could it be that the CPU either doesn't support floating point operations

The F103 does not support a hardware FPU, so I already added -mfloat-abi=soft -msoft-float a while ago, it seems just there is some pice of the puzzle still missing.

 

8 hours ago, electric_vehicle_lover said:

I don't have a bicycle computer with me to measure the velocity of the wheel

Well I meant that with just the duty cycle it would be possible to ride (maybe 5-10), the current feedback should be read in and passed to a PID regulation also, to achieve some constant torque. Without that, the main PID may have more difficulties to regulate just on the known speed (RPMs) and can not react so fast on voltage sags, or voltage drain, hills or other slow down / accel forces from outside?

WIthout somebody on the wheel, the motor can probably spin up to 50-60km/h (just a small guess), but the tourqe at this speed will not allow riding.

[Tomek]

@jayjay23 & all contributing to the open EUC firmware

you guys ROCK!

I've been following this thread and am deeply impressed with how fast you're moving. This project has so much potential to accelerate developments in the whole world of EUCs by providing a reliable, solid and safe platform which can be further adapted by hobbyists and EUC producers alike. I'm only an amateur programmer, but hope to be able to contribute with testing and small tweaks as soon as the core features are in place.

[electric_vehicle_lover]

Thanks @Tomek and also take this as an opportunity to learn ;-) :-)

[jayjay23]

7 hours ago, esaj said:

 I was able to figure out that the HardFault_Handler was what was actually being called.

I read somewhere that there is a chain and WWDG is just the last one, so I actually put in my head 'something is not working' (generally), without care actually about the WWDG specifics.