Can the PWM signal be affected by computational load?

[hippicurean]

Hi there,

I'm using Simulink/Matlab and nxtOSEK to design an adaptive control algorithm for the NXT. For those who aren't aware, nxtOSEK uses some rather old leJOS drivers to interface with the sensors and motors. Now, I've been wondering for some time why my vehicle cannot maintain a smooth run but instead stops and starts. The simulations on the PC don't indicate that the signals to the motors are pulsed. During the moments when the vehicle has come to a temporary rest, a high-pitched whine is quite audible. I've read before that it's due to the PWM signal. Pushing the vehicle doesn't help. On a hunch, I picked up the vehicle and tried to turn the wheels manually. I was surprised how easily I could rotate them. It's obvious that the motors are receiving a current that isn't quite enough to overcome the frictional torque.

During previous calibration runs, I noted that the vehicle will barely manage a crawl with a PWM duty cycle set to 15%. I've gone back to my program and decoupled the control algorithm from the motors and assigned a series of constant signals (i.e. duty cycle settings) to the motors. While the control algorithm no longer has any effect on the motors, it's still running and placing a computational load on the ARM7 processor. With the duty cycle set at 50% in this set-up, the motors won't spin even when the vehicle is held in the air and presents no load. The vehicle will manage a crawl when the duty cycle is raised to 60%. No wonder it has been stalling so often; it stops any time the PWM signal falls below 60%.

It seems that computational load has a significant effect on the PWM signal. Yet strangely, setting the PWM duty cycle to 100% will result in the same vehicle speed with or without additional computations running in the background. Could someone please explain this phenomenon? Thanks.

Cheers
Hippie

[gloomyandy]

The PWM for the motors is not generated by the AT91 (ARM) chip it is controlled by the ATMega (and I think is generated by hardware), so it seems unlikely that load on the main processor will impact it directly. So you may have to look deeper to work out what is going on. It may be that the handshake between the two processors is not working correctly when the AT91 is heavily loaded. Alternately could you be overloading the motor drivers? These have a thermal cut out and will drop all power to the motors for a few seconds if they are triggered. I've seen this happen a lot with Segway type robots which are basically driving the motors in a near stalled condition. As to the poor motor control, you may want to try changing the PWM drive mode being used. Basically this specifies what happens during the PWM off cycle, in so called "float" mode the motor driver chip basically disconnects the motor during the off cycle, in "brake" mode the driver will in effect short out the motor windings. with the NXT you get much better motor control when using brake mode, with float mode you need to have a pwm cycle up around 30% before the motor will even turn, in brake mode it will turn at 6%. I'm not sure how you set the pwm modes in nxtOSEK but in the current version of leJOS you use the nxt_motor_set_speed function.

You may find the following of interest:
http://www.gloomy-place.com/images/lejospid.pdf
http://www.gloomy-place.com/lejosmotor.htm

Andy

[hippicurean]

Andy, you identified the problem straightaway! The motors in the simple calibration program are on brake mode while the motors in the adaptive control program are on coast/float mode. I didn't realise there was such a stark difference between the two motor settings. Thanks for your insight and for the informative articles on the NXT motors. Cheers!