Firmware

[electric_vehicle_lover]

So, I "connected" the output signal/value from the IMU to the motor controller :-)
Before, I decided to use the board in horizontal and tested it, seems to work correctly - my idea is to prove we will be able to place the boards horizontal or any other orientation, when doing our mods!!

As always, you can find the OpenSource code on github: https://github.com/generic-electric-unicycle/firmware/

On the next video, the result. It is not very good and I now think the problem may be the very slow ramp of increasing duty-cycle:

 

[vezu4iy]

Can you make like in video?

 

 

Edited February 15, 2016 by vezu4iy

[Restless]

Hey guys.

@electric_vehicle_lover i just wanted to say: Love your work and its awesome to see your progress. Sadly i  don't have enough time at the moment to contribute more to this project.

Just wanted to thank you

[vezu4iy]

It works, result will be better

[electric_vehicle_lover]

1 hour ago, vezu4iy said:

Can you make like in video?

It's the same code, but now with the input come from the angle and not from the potentiometer. Something is not working well... I tested the angle code before and was working well, I think.

[vezu4iy]

Can I help you?

[electric_vehicle_lover]

11 minutes ago, vezu4iy said:

Can I help you?

Yes!! Please read the code and try understand If there is something wrong, etc: https://github.com/generic-electric-unicycle/firmware/

[vezu4iy]

Ok! I will do it best!

[electric_vehicle_lover]

So I found there was an error from converting a float to int ;-) -- here is the code working, the EUC seems to try balance :-)

 

[Restless]

Is your motor alright? It sounds a littlebit awefull to me  Like metal scratching or something?

[electric_vehicle_lover]

3 hours ago, Restless said:

Is your motor alright? It sounds a littlebit awefull to me  Like metal scratching or something?

That's the EUC that I use for myself and also for the firmware development. The motor is ok. The current firmware code for motor control should be somehow different from the firmware of original board. That noise seems to be the motor vibrating... in the begin, that noise were worst but now is really better. Anyway, for this phase I think the motor code should be ok for slow to medium velocity - we can now in parallel develop other piece of codes while someone can focus only on the motor control.

Current motor interface is this:  motor_set_duty_cycle (value);
Value: -999 <--> 1000. Negative values motor rotate to left, 0 motor stopped and positive values motor rotates right.

[vezu4iy]

I think the motor is noising because of the vibrations. The vibrations is transfering to  MPU6050.

Test the board unscrewing the motor housing and change the angle by your hands.

[vezu4iy]

Try and make video

 

[electric_vehicle_lover]

16 hours ago, vezu4iy said:

I think the motor is noising because of the vibrations. The vibrations is transfering to  MPU6050.

Test the board unscrewing the motor housing and change the angle by your hands.

I already tested the board for angle, without the motor. I also did the same for the motor controller.

But to say the true, I don't know what is need to be done next!!! and so I am reading some of the many OpenSource projects of "Arduino balance robot" like this one: http://www.kerrywong.com/2012/03/08/a-self-balancing-robot-i/

I <3 OpenSource ;-) :-)

[vezu4iy]

Is the sound  awefull? What is about a result? Is it the same sound?

Edited February 16, 2016 by vezu4iy

[vezu4iy]

 

in the code you need to add softness control . The engine should respond with a slight delay , and not to respond to twitching .

[electric_vehicle_lover]

45 minutes ago, vezu4iy said:

 

in the code you need to add softness control . The engine should respond with a slight delay , and not to respond to twitching .

@vezu4iy I must say that I have difficult to understand your communications. Can you please explain a bit better what you mean??

@OliverH many thanks for the boards!! I got them and they will accelerate my development :-) -- to say the true, the code should be near, as there are many people that did "balancing robot/unicycles" using Arduino and they share their OpenSource code and explanations!!

Edited February 16, 2016 by electric_vehicle_lover

[OliverH]

2 minutes ago, electric_vehicle_lover said:

I must say that I difficult to understand your communications. Can you please explain a bit better what you mean??

@OliverH many thanks for the boards!! I got them and they will accelerate my development :-) -- to say the true, the code should be near, as there are many people that did "balancing robot/unicycles" using Arduino and they share their OpenSource code and explanations!!

Fine. Better they're used at the right point Looking forward to see the first prototype running.

[chriscalandro]

Are you averaging the values from the MPU6050 or using them directly?

 

In my experience taking several quick readings, averaging them together, then using those values to feed the PID makes things smooth out nicely...

 

I'll have a look at your code later on.

 

also, it sounds a lot like the motor driver is out of sync.

Edited February 16, 2016 by chriscalandro

[Berus]

@electric_vehicle_lover

I'm following this project, I ' m interested to understand how euc work.

I bought my first euc two month ago, before I never read something about BLDC commutation and when I was thinking on how the software/hardware can keep the EUC in vertical position, turn  the pedals on warning..  my thought was:

the imu /cpu board are fixed to the body+pedals+motor shaft ..so  the software calculate the actual angle an then in some way it can control and rotate the motor shaft

:D:D:wacko:

Yes I forgot the inverse pendulum theory.

So be patient if my questions are boring or my suggestion are unusefull

I have read several docs about bldc motor and some code about imu balancing(your code and the code at openwheel.cc) and other docs.

To be honest I haven't understand which type of  motor commutation  you are using .. Sinusoidal,FOC or 6 step.,
I know that stm32 have firmaware libraries for FOC and six step commutation.
The first thought when you speak about noise/vibration of the motor, was this in my mind :

 

link for fun

http://aidilj.com/2015/01/sensored-bldc-motor-control-with-arduino/

Edited February 17, 2016 by Berus

[electric_vehicle_lover]

@Berus thank you for reading my code. I will give feedback when possible.

I am trying to follow the same control methods I verified on the original boards - please see the wiki where I documented with oscilloscope screenshots.

The pendulum, for what I read on Arduino projects, the task is to make the angle equal to zero!! (Read angle, calc the error and use PID to calc the duty-cycle for the motor). If there is positive deviation we rotate the motor for right and vice-versa -- very easy to understand. When we ride the EUC, we are making an deviation on the angle of the pendulum and the motor should quick rotate on the same direction of the angle -- seems very easy to understand and implement :-) as many others did using Arduino.

[Berus]

8 minutes ago, electric_vehicle_lover said:

@Berus thank you for reading my code. I will give feedback when possible.

I am trying to follow the same control methods I verified on the original boards - please see the wiki where I documented with oscilloscope screenshots.

The pendulum, for what I read on Arduino projects, the task is to make the angle equal to zero!! (Read angle, calc the error and use PID to calc the duty-cycle for the motor). If there is positive deviation we rotate the motor for right and vice-versa -- very easy to understand. When we ride the EUC, we are making an deviation on the angle of the pendulum and the motor should quick rotate on the same direction of the angle -- seems very easy to understand and implement :-) as many others did using Arduino.

thank you for your reply and patience

Ok .six step. I understand that you want follow the same/original, but as experiment  I was curios to see a FOC control on a EUC motor  ... so I was hoping that you had secretly tried it

[electric_vehicle_lover]

16 hours ago, chriscalandro said:

Are you averaging the values from the MPU6050 or using them directly?

In my experience taking several quick readings, averaging them together, then using those values to feed the PID makes things smooth out nicely...

I'll have a look at your code later on.

also, it sounds a lot like the motor driver is out of sync.

@chriscalandro I am not averaging the values but I am using the complementary filter.

Yes, the motor works but is not perfect...

Thanks.

@Berus I can't develop such complex algorithm as FOC, maybe someone will. Also this project is OpenSource and I would not be developing secretly.  

Edited February 17, 2016 by electric_vehicle_lover

[Berus]

2 hours ago, electric_vehicle_lover said:

@Berus I can't develop such complex algorithm as FOC, maybe someone will. Also this project is OpenSource and I would not be developing secretly.  

Of course my "secretly" was intended as " experiment" out of this project ... as curiosity in bldc control.you can make a opensource project a make something else with same hardware

ok if it's complex ...no way  ...my error , words as "one touch tuning" words made me believe that it was not very complex

STM32 PMSM FOC Software Development Kit    ST MC Workbench

another link

The user, through a graphical user interface (GUI), generates all parameter header files which configure the library according to the application needs and can in real time monitor and change some variables of the algorithm.

Motor Profiler and one Touch Tuning for a fast startup of unknown motors.

Speed/position sensors (Encoder and Hall) as well as sensorless operation

 

Thanks for your time ..I will continue to follow your good work

 

 

Edited February 17, 2016 by Berus

[chriscalandro]

looking through the firmware -

Do you have a measurement of the loop for getting the readings from the gyro?

 

Again, I really think you should take several samples and average it.  I think one of your issues is the vibration of the motor is messing with the gyro and cascading issues through the code.  Averaging, and maybe slowing down the loop might help troubleshoot, you can always take it out later.

 

Going to start looking at the motor driver.