Hi,
I have a new Orangutan X2 (1284/328) with VNH2. The Orangutan is connected to 2 x 12V DC motors and a 12V DC power supply. The firmware is written such that an explicit command must be sent to the Orangutan through the serial connection before the motors move. Sometimes, I notice that when I power-up the Orangutan, one motor will start running on its own. When I switch off the Orangutan and then power it up again, this does not happen and the behavior seems fine. Do I need to implement some delay power-up function on the 328 (which I presume controls the VNH2) to prevent this random starting from happening?
Thanks.
Hello.
I am sorry you are having trouble with the Orangutan X2.
Yes, the ATmega328P on the board controls the VNH2 motor driver.
What is the format of the explicit command that must be sent through the serial connection to turn on the motors? Have you figured out whether the ATmega1284 is commanding the motors to start? Maybe it should keep a little record of the last motor speed command it sent so you can see if it is sending that command.
If that doesn’t yield any results, I think I would try turning the motors off at the beginning of your program, then delaying for 10-100 ms, and then turning them off again.
–David
Hi David,
When you say turning the motors off, do you mean cutting off the power supply to them physically?
In the firmware, upon starting the Orangutan, I have set motor speeds to 0, delay 10-100ms, then set them to 0 again. I have also removed all code that makes the motors move in the main() routine. However, the sudden motor start still happens at times, and it always happens to 1 motor.
Regards,
I didn’t mean to cut off the power supply physically. It sounds like you did exactly what I was suggesting, and went a step further; you removed all the code that sets the motors to a non-zero speed, right?
How reproducible is this? If you power cycle for a minute can you usually get it to happen? If it is reproducible, I suggest totally erasing the program on your Orangutan X2, just to be sure that it isn’t doing anything to start the motor, and see if the problem is still happening. AVRDUDE and AVR/Atmel Studio have commands for erasing the target chip.
If the problem goes away after erasing, then it means the problem is most likely caused by your code, and you should be able to simplify your code to the simplest possible thing that causes the problem.
Also, could you give us more details about your setup, like what components do you have and how they are connected? A picture might help us spot something.
–David
Yes, I have removed all the code that enables the motors to move. But one of the motors still starts on its own at times.
I have uploaded the pictures of my set-up here. It shows the Orangutan connected to 2 x 12V DC motors, a DC power supply, and a USB connection to the computer.
The problem is not very reproducible. It happens about 20% of the time when I boot-up the Orangutan.
Thanks for the pictures!
Depending on how complex your code is, there might still be something in there that unintentionally causes the motors to move. Any code that communicates with the auxiliary processor is especially suspect. That’s why I recommended erasing the chip.
If it happens 20% of the time, that sounds pretty reproducible. If you boot up the Orangutan 20 times, there is almost a 99% chance you will see the problem. You should be able to unplug and replug the red banana cable’s connection to your power supply tens of times per minute.
So if you erase the chip and try power cycling it many times, does the problem still happen?
Those motors look kind of big. Do you know what their stall current is? I wouldn’t expect the size of the motor to affect anything before the motor driver starts trying to drive it, but you could try removing the motors and just look at the motor direction LEDs on the motor driver board to see if the problem is still happening.
–David
A quick check: Is it appropriate to use the below fuse bits with the Orangutan X2’s ATmega1284P? Full-Swing Oscillator, Start-Up Time: 1K CK + 4.1 ms, Ceramic Resonator.
Attached is a screenshot of the fuse bits currently used for our Orangutan X2.
The fuses we program onto the ATmega1284P on the Orangutan X2 are:
Extended: 0xFF
High: 0xD9
Low: 0xF6
You should compare these to what you see in AVR Studio to make sure they match. There might be some discrepancies in some of the bits because avrdude and AVR Studio disagree about whether unused bits should be 1 or 0, but the bits that actually matter should match. If you post another screenshot with the extended/high/low values visible I could help you figure it out.
–David
