jhaupt / nearzero1 Goto Github PK

Connected two robowheels to one near zero, operating voltage is 36 and batteries are 7 ah.

channel 1: 1000 ma operating current, 200 ma testing current
Channel 2: 1000 ma operating current, 200 ma testing current

tested in both pwm and i2c mode. This happens after changing the direction of spinning of the motors. Irrespective of the speed the bug has been reproduced at different current settings.

Functions.ino line 760
if(pwm1_t > 0){ //Is the pwm active?

pwm1_t and pwm2_t are only set to 0 prior to setup() until the first pwm signal is received. After that, they always hold some positive value. That value is only set by ISR_pwm1() which will not occur if the R/C transmitter is switched off or goes out of range. The result is motors keep turning at the last speed unless R/C transmitter is switched back on and signal is set to neutral, or power is disconnected. There needs to be something like
// PWMtimeout around 100mS
if (micros() - risemark1 > PWMtimeout) { pwm1_t = 0; pwm2_t = 0; }

I spotted this Lib someone wrote: https://github.com/gsteixeira/nzero-library

I was wondering if someone with a bot could test the code? Maybe @jhaupt would review the code and fork it into this repo to make it more official/visible?

With some motors, the controller never gets out of the initial current calibration. I think this is because the resistance of the motor is too large to reach the target current even with maximum duty. If I start up the controller with a different motor and switch back to the higher resistance motor after the calibration, I can use the motor without any problems. This is a little cumbersome though.

One possible solution would be to allow the user to skip the calibration and control the motor directly by duty instead of by current. This may be desirable for other reasons too.

A related issue is that when sending I2C commands with a high current, there is no check that the resulting duty is not too high. This leads to overflows and violent jumps in motor position. It's not easy for the user to know what the maximum current that can be used is, because it will be different for different motors. This would also be easier if controlling directly by duty.

In the functions Roll1_vel() and Roll2_vel() the following code is supposed to keep the phase index in the interval 0 to 2*pi:

	//RESET PHASE INDEX AFTER 2PI
	if (phaseindex1 >= 2*pi) {   //Reset phaseindex_U1 once it completes 2*180o in phase.
		phaseindex1 = 0;
	}
	else if (phaseindex1 <= 0){
		phaseindex1 = 2*pi - phaseindex1;
	}

For the case of phaseindex1 <= 0, I believe is should really be phaseindex1 = 2*pi + phaseindex1; rather than phaseindex1 = 2*pi - phaseindex1;. For the case of phaseindex1 >= 2*pi, it's not really wrong, but setting it to 0 could cause a small speed inconsistency. It would be better to use phaseindex1 = phaseindex1 - 2*pi;.

All together, I would propose the following code:

	//RESET PHASE INDEX AFTER 2PI
	if (phaseindex1 >= 2*pi) {   //Reset phaseindex_U1 once it completes 2*180o in phase.
		phaseindex1 -= 2*pi;
	}
	else if (phaseindex1 < 0){
		phaseindex1 += 2*pi;
	}

The reason I found this was that I experienced that the motor got stuck after rotating just a little bit at certain speeds. I believe this is due to the controller getting stuck in an infinite loop jumping between the edge cases. It only seems to happen at certain negative speeds, which I think is due to floating point imprecision.