Jump to content
jayjay23

Firmware

Recommended Posts

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 by electric_vehicle_lover
  • Upvote 2

Share this post


Link to post
Share on other sites

@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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Upvote 1

Share this post


Link to post
Share on other sites

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.

Screenshot_2015-12-19-15-44-47.thumb.png

Share this post


Link to post
Share on other sites

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.

TB2hMjLbXXXXXX1XXXXXXXXXXXX_!!464113997.jpg_600x600.jpg

  • Upvote 1

Share this post


Link to post
Share on other sites

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 :-)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 :-)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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...

  • Upvote 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

  • Upvote 3

Share this post


Link to post
Share on other sites

@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.

  • Upvote 1

Share this post


Link to post
Share on other sites
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.

  • Upvote 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×