Firmware

[chriscalandro]

integral_term = sum_error * dt * KI / KP * 10.0; // 0.0005

 

change this to  integral_term = sum_error * dt * KI / KP * 5.0; // 0.0005

 

post the result please!

 

also try  integral_term = sum_error * dt * KI / KP * 2.0; // 0.0005

[electric_vehicle_lover]

I am moving home so on next week I think I will not be able to try. Anyway, I already tried to change the P I and D values. The P value, I could not make it work well. Anyway, I now think that PID as used on balance bots is not OK for EUC.

What I want try next: at a 1ms, put a positive and after a negative duty-dycle. I want to be on the case where the wheel is on balance and need the less energy to keep it. The PID would end with this situation and so I want to try it and understand how much energy/ duty-cycle this motor needs to keep the balance while I hold the EUC with my hand.

[vezu4iy]

 

less energy the more stable

[chriscalandro]

Which is what changing the P multiplier does. 

PID is required and were very close to having this balance. 

If I had the parts I could do it, but I don't so I can't, and I'm not about to spend the money to do it. 

[vezu4iy]

If You have original firmware, I can use my divice for experiments

[chriscalandro]

Well here's another thought,

If you did the pid correct a P multiplier of 0 should mean the motor never moves. 

 

Is that the case?

 

I'm going to look over it more closely later in the week. 

[electric_vehicle_lover]

Yes, the motor never moves if P is 0 because the duty_cycle calc will be 0.

I were able to try this code (trying cycles of 1ms up to 50ms and diferente duty_cycle values):

if (duty == 1)
{
    motor_set_duty_cycle (150);
    duty = 0;
}
else if (duty == 0)
{
    motor_set_duty_cycle (-150);
    duty = 1;
}

and the motor vibrates to much and don't stay "blocked" as on the original firmware. I think I need to work more on the motor driver.

[OliverH]

1 hour ago, electric_vehicle_lover said:

Yes, the motor never moves if P is 0 because the duty_cycle calc will be 0.

I were able to try this code (trying cycles of 1ms up to 50ms and diferente duty_cycle values):

if (duty == 1)
{
    motor_set_duty_cycle (150);
    duty = 0;
}
else if (duty == 0)
{
    motor_set_duty_cycle (-150);
    duty = 1;
}

and the motor vibrates to much and don't stay "blocked" as on the original firmware. I think I need to work more on the motor driver.

The order of the hall sensors cables are correct? In case there's a different pinout.
Only to make sure it's a software/ config error and not wrong connected sensors.

[electric_vehicle_lover]

10 minutes ago, OliverH said:

The order of the hall sensors cables are correct? In case there's a different pinout.
Only to make sure it's a software/ config error and not wrong connected sensors.

The motor runs with this connections so they should be ok. The question may be that the motor firmware driver is no ok yet for this application (similar to original firmware).

[vezu4iy]

Conections is OK!

 

[vezu4iy]

Watch this video again. Speed and duty cycle is minimal. 

 

[vezu4iy]

Maybe 

http://rspa.royalsocietypublishing.org/content/early/2010/01/18/rspa.2009.0559

[electric_vehicle_lover]

@vezu4iy, thanks for the video!! I decided to make my latest test after seeing the video you shared and after I remembered my own unicycle. And yes, I also think duty-cycle and speed are minimal on the equilibrium.

Thanks for this link, I will really appreciate to read it: http://rspa.royalsocietypublishing.org/content/early/2010/01/18/rspa.2009.0559#sec-8

[vezu4iy]

 

I think should be the minimum duty-cycle change, but not the duty-cycle

[chriscalandro]

If you now change that P value to .5 you should be able to acheive a very "floppy" balance with a wide margin of error. 

 

The larger you make that number, the smaller the error will be. 

 

At some point you will over compensate(what you had with a multiplier of 10) and you will need to back off again. 

I have built no less than 3 balancing robots. I promise this is the answer. (Unless it's the motor driver)

 

Again the speed at which you reach the balance is meaningless if you never achieve balance. 

 

Get it to work first, then make it fancy. 

Edited February 23, 2016 by chriscalandro

[electric_vehicle_lover]

@chriscalandro thanks. And why type of motors did you use?? -- I believe the current driver motor may have some problems.

[vezu4iy]

try all values

[chriscalandro]

I have only done DC motors. 

Do you have skype?

If we can come up with a time to talk while you have everything near you we can get this done faster. 

Edited February 23, 2016 by chriscalandro

[vezu4iy]

duty-cycle is minimal. its about 5-10%

 

[electric_vehicle_lover]

@chriscalandro I appreciate your availability for o skype. This project uses brushless motors that are more difficult to control. On top of that, we do not have documentation for this motors and their control on the original firmwares are really different from usual methods. I need to work more on the motor controller before the PID and balance.

Please keep connected to this thread and we will discuss later your help.

[chriscalandro]

Alright, I think I have some time to poke through the motor control today...

 

Here is the first thing I notice

With this code, if there are 6 sectors, you never actually get to sector 6 while incrementing, and you never get to sector 1 while decrementing, because while incrementing, if the sector = 6, then the sector  = 1

 

you have this

unsigned int increment_sector (unsigned int sector)
	{
	if (sector < 6)
	{
	sector++;
	}
	else // sector = 6
	{
	sector = 1;
	}
	return sector;
	}
	unsigned int decrement_sector (unsigned int sector)
	{
	if (sector > 1)
	{
	sector--;
	}
	else // sector = 1
	{
	sector = 6;
	}
	return sector;
	}

I believe you should have something like this

	{
	if (sector < 7)
	{
	sector++;
	}
	if (sector == 7) // sector = 7
	{
	sector = 1;
	}
	return sector;
	}
	unsigned int decrement_sector (unsigned int sector)
	{
	if (sector > )
	{
	sector--;
	}
	if (sector == 0) // sector = 0
	{
	sector = 6;
	}
	return sector;
	}

 

 

Edited March 1, 2016 by chriscalandro

[electric_vehicle_lover]

Thanks!! I am blocked on the  motor code

[chriscalandro]

I edited my earlier response.  Check it out.  This would probably solve the terrible noise and the sync issue it sounds like you have as well!

 

You were doing 

1 - 2 - 3 - 4 -5 - 1 - 2 - 3 - 4 - 5 

and

6 - 5 - 4 - 3 - 2 - 6 - 5 - 4 - 3 - 2 

Edited March 1, 2016 by chriscalandro

[chriscalandro]

Did you write the motor code or just implement it?

 

Did you have to edit for number of windings?

[electric_vehicle_lover]

I really appreciate your effort. It made me think again on that code and I am pretty sure it is correct. I remember to see it running using the debugger.

Can you please review that code again? 

What I do is to verify if variable is lower than 6 and increment. Else, then the variable is set to 1.

I did the motor code myself but taking as reference many other OpenSource codes and application notes.

I believe the number of windings have no effect on the code, at least I didn't saw any example code for it!!!

Edited March 1, 2016 by electric_vehicle_lover