PWM motor driving, serial communication, and gyro (mpu9250) issues with Nano

[Elryk]

Ok, I am making a quadrotor with an arduino nano for a brain. It is controlled with commands sent over serial through a HC-06 Bluetooth module. It is supposed to use the mpu9250 for stabilization. I have run into 2 problems. The problems:

1. When the motors are given power, they shutdown after a brief but random time. Serial communication stops (mid stream if the arduino is transmitting) when the motors stop. The TX light either stays on, or flashes so fast it looks like its staying on when the motors stop. Basic bare code that only sets the pwm rate and analogWrites works fine. Before I added the command structuring (checking serial for commands and adding # and / to the commands), everything including the motors worked as expected. Adding the structure for commands is seems to be what causes the issue. As long as the motors do not have power, everything works as expected, except for the other problem below:

2. The mpu9250 does not appear to be working at all. WhoAmI is supposed to report 71, but reports FF. The reported values for x, y, and z fluctuate wildly while the quad is stationary, and the fluctuations and value ranges do not seem to change when the quad's orientation is changed. I changed the If statement that checks the WhoAmI value, so it checks for FF instead of 71, but that didnt help.

The code for the MPU is a copy and paste from MPU9250BasicAHRS.Ino by Kris Winer. I basically just took out all of the display and serial debug stuff. The rest of the code was written by me.

To Be Continued...

[Elryk]

Wow, over 9000 sucks. Apparently my code is too long to easily post, so here are the files instead. The code for the 9250 requires an additional file called quarternionFilters.ino to be in the same folder. I did not edit the contents of the original filters file, just copied it.

The motors have 4148 diodes across them (reversed polarity). The mosfets have built in protection diodes and are sitting as low side switches for the motors. The mosfets are driven through 390 ohm resistors directly from the nano. the nano (VIN pin) and the motors are powered from a 3s lipo (11.1v, measures at about 12.5v full charge). The HC-06 and MPU9250 are powered from the nano's 5v pin.

Any troubleshooting steps not mentioned here, or possible solutions, are greatly appreciated. If you need/want any additional info, let me know and I'll get it here asap.

Thanks,
Kyrle

QuadCopterV0.2.ino (52.4 KB)

quaternionFilters.ino (9.2 KB)

[CrossRoads]

I'd rather see files anyway, less chance for cut & paste errors.

[Elryk]

Oh yea, I also have a question about abs() in a couple of formulas I use. They can be found in the command section (where CmdQ is read and executed) in the switch case block:

LeftControl = int(CX / 2) + ((CX - (2 * (int(CX / 2)))) + abs(CX - (2 * (int(CX / 2))) - 1) / 2);

The last half has int() inside of abs(). Refrence says that functions should not be used inside abs(). Does that apply to int()? Could this be a problem? Id rather not have to make another temp variable if avoidable. It already looks like I'm going to get dangerously close to maxing ram.

[Robin2]

Elryk:

1. When the motors are given power, they shutdown after a brief but random time. Serial communication stops (mid stream if the arduino is transmitting) when the motors stop.

That sounds like the motors are drawing too much current causing the voltage to drop and causing the Arduino to reset.

...R

[Elryk]

Robin2:
That sounds like the motors are drawing too much current causing the voltage to drop and causing the Arduino to reset.

...R

That doesnt seem very likely. Its a New (4 charge cycles, less than a month old) 25C 800mah 3s (11.1v) lipo. The maximum current I have measured on each motor is about 1.6A at full power (I havnt given them full power yet with this code, only about 40%-50%). That would mean less than 7A is dropping the battery to about 60% voltage (Vin needs 7v right?). My understanding is that this battery should be able to supply up to about 20A without a significant voltage drop like that (assuming full charge, which it is). This also doesnt explain the led behavior after the motors shut down. Also, this issue only popped up when I added the code for the command system, leading me to believe this is a code issue, not hardware (I havn't completely ruled out hardware as a possibility, it just seems unlikely).

That being said, I will try to monitor the voltage when I power up the motors and report back with the results when I am off work.

Thanks

[Robin2]

Elryk:
leading me to believe this is a code issue, not hardware

You may well be right. One way to rule out the battery is to use a much bigger one temporarily.

Another risk to examine is a poor connection somewhere that presents a significant resistance for higher currents.

The few time I have had power supply problems the symptoms looked very like a software problem.

And, sorry, but I am too lazy to study 52k of code.

...R

[Elryk]

I have done some voltage tests on the battery.

Everything off (at main battery switch): 12.49v
Switch on, BT, MPU, and Nano on, no pwm to motors (motors off): 12.49v
Motors on at 50% (shutdown bug occurs): 12.36v

Its also worth noting, the motors stayed on for about 1 second this time, and the voltage held steady at 12.36v until the motors shut down, and it returned to 12.49v.

[Elryk]

The motor shutdown issue seems to have fixed itself. I decided to do a check to see if it was the motors running, or something else causing the problem, so I added Power[0] = 30; at the beginning of setup, so that instead of shutting the motors off first thing on startup, it runs them really slow.

This test worked. The motors spun slowly as expected and did not shut down. So I increased power through the BT serial connection using the commands. I successfully brought power up to about 90% before deciding it was a good enough test.

I then commented out the added Power line and tried again. Complete success up to 100%. Then I backed it off to a stable idle that would cause a shut down before, and let it run for a few minutes It worked perfectly. Serial still worked at the end (used it to power down) and the motors were shut down by me for a change, instead of randomly.

If anyone has any ideas as to why that was happening, I'd still like to investigate possibilities. I'm not a fan of self fixing problems, I'd rather know whats wrong and fix it myself. I'm glad it works, I just wish I knew why its working now and wasnt before.

So, now that just leaves the issue with the 9250. Still scratching my head on that one. Apparently I cant even get it to connect (I'm assuming thats what the FF means). Anyone have any experience with the 9250? Even if its with a different library, I'm willing to switch or try a different one. As long as I can get X,Y,Z orientation from it, it will work.

[Robin2]

Elryk:
The motor shutdown issue seems to have fixed itself. I decided to do a check to see if it was the motors running, or something else causing the problem, so I added Power[0] = 30; at the beginning of setup, so that instead of shutting the motors off first thing on startup, it runs them really slow.

By running the motor very slowly you may be avoiding a large inrush current when the motor starts and ramps up to full power. The short high-current draw that may be causing a problem may be much too short to be detectable without an oscilloscope.

...R

[TomGeorge]

Hi,

Can you please post a complete copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png?
(PS Not a fritzy image..)

Also a picture of your project so we can see your component layout?

How have you got the power supply wires to the motors?
Direct to the battery for the motor supply is the best design and separate wiring to the battery for the Arduino control system, that is all in a star configuration.

What MOSFETS are you using?

Can you post the motor type/model link to data/specs please?

You say you are having problems with the MPU unit, have you tested it with just a simple bit of code?

Thanks.. Tom...
PS, When you ran the motors did you have them loaded, that is with props fitted?

[55thSwiss]

Elryk:
The motor shutdown issue seems to have fixed itself. I decided to do a check to see if it was the motors running, or something else causing the problem, so I added Power[0] = 30; at the beginning of setup, so that instead of shutting the motors off first thing on startup, it runs them really slow.

This test worked. The motors spun slowly as expected and did not shut down. So I increased power through the BT serial connection using the commands. I successfully brought power up to about 90% before deciding it was a good enough test.

I then commented out the added Power line and tried again. Complete success up to 100%. Then I backed it off to a stable idle that would cause a shut down before, and let it run for a few minutes It worked perfectly. Serial still worked at the end (used it to power down) and the motors were shut down by me for a change, instead of randomly.

If anyone has any ideas as to why that was happening, I'd still like to investigate possibilities. I'm not a fan of self fixing problems, I'd rather know whats wrong and fix it myself. I'm glad it works, I just wish I knew why its working now and wasnt before.

So, now that just leaves the issue with the 9250. Still scratching my head on that one. Apparently I cant even get it to connect (I'm assuming thats what the FF means). Anyone have any experience with the 9250? Even if its with a different library, I'm willing to switch or try a different one. As long as I can get X,Y,Z orientation from it, it will work.

Robin2:
By running the motor very slowly you may be avoiding a large inrush current when the motor starts and ramps up to full power. The short high-current draw that may be causing a problem may be much too short to be detectable without an oscilloscope.

...R

Seems like good troubleshooting step. Is there actually a problem with avoiding a current flux like this by ramping the RPM up? Seems ok to me?

[Elryk]

Robin2:
By running the motor very slowly you may be avoiding a large inrush current when the motor starts and ramps up to full power. The short high-current draw that may be causing a problem may be much too short to be detectable without an oscilloscope.

...R

If that was the case, it is no longer a problem. I tested from motors stopped to full power multiple times last night and never had a random shutdown. The test involving starting at low power at the beginning of setup was only done once. After that one test, the line starting power at 30 instead of 0 was taken out and has not been used since. I am currently using the code I originally posted.

TomGeorge:
Hi,

Can you please post a complete copy of your circuit, in CAD or a picture of a hand drawn circuit in jpg, png?
(PS Not a fritzy image..)

Also a picture of your project so we can see your component layout?

How have you got the power supply wires to the motors?
Direct to the battery for the motor supply is the best design and separate wiring to the battery for the Arduino control system, that is all in a star configuration.

What MOSFETS are you using?

Can you post the motor type/model link to data/specs please?

You say you are having problems with the MPU unit, have you tested it with just a simple bit of code?

Thanks.. Tom...
PS, When you ran the motors did you have them loaded, that is with props fitted?

I'll have to get the circuit drawn out in multisim and posted when I get off work.

Same goes for the picture of the project.

The motors are directly connected to the battery (after the power switch). The arduino (VIN pin) is also directly connected to the battery.

Mosfets are: 785-1647-5-ND N-CH 100V 14A TO-251

The motors are unknown They have no ID markings, They are some spare 12v motors that had reduction gear boxes on them, beyond that, I have no info.

I have not tried the MPU code on its own, It is already as simple as it can get I think and is not yet integrated with the rest of the sketch, it runs independently. Ill try to run the mpu code by itself and see if it works. I also intend to try a different example as well, but I dont have high hopes since the new one to try says its for 9250, but the file names say 6050

The motors are loaded. Props have been on from the start, even for un-mounted testing.

55thSwiss:
Seems like good troubleshooting step. Is there actually a problem with avoiding a current flux like this by ramping the RPM up? Seems ok to me?

It would only be a problem if it needed to be ramped slowly, if the power change has to be too slow maneuverability will suffer. In fact, the power will rarely jump from one value directly to another, it will incrementally move to the new value most of the time.

[TomGeorge]

Hi

Mosfets are: 785-1647-5-ND N-CH 100V 14A TO-251

Sorry, what is the manufacturer part number?
I think that is a digikey number, link to specs please, is it logic level?

Tom...

[Elryk]

Your right, that was the digikey part number. Sorry about that. heres a link to the datasheet:

AOI4286.pdf

And the Mfg and part number:
Alpha Omega Semiconductors AOI4286

EDIT: Added schematic and top pic

[Elryk]

Here is the bottom pic, with a better view of most of the components.

[TomGeorge]

Hi,
I'm sorry but where are your MOSFETs?
Where is the battery?
And you do need to beef those copper tracks up.
OPs Pics

Tom...

[Elryk]

The MOSFETs are on the bottom in the corners of the main body. You can easily see 3 of them. The 4th is mostly covered by the nano in the pic but you can see part of it.

The battery is not in the pics, it gets strapped under the black Velcro. It would have been hard to get informative pictures with it attached.

I can't do much about the track sizes without adding excessive weight or essentially starting over. Fortunately, it doesn't seem to be an issue. The tracks don't even get a little warm and perform better than the wires I did my prebuild testing with (the motors spin a bit faster). Is there another reason beyond performance and heat that makes you think they need to be bigger?

[TomGeorge]

Hi,
Have you tethered the quad with say 4 lengths of 20cm of string and see if it can lift off the bench?

Place 0.1uF bypass capacitors on power wires at the nano and the power wires going into the MPU at the MPU.

Thanks.. Tom..

[Elryk]

I have not done a tethered test like that, but it has accidently 'flown' twice. There is enough lift, and I'm still not done with weight reduction.

I should have thought of a bypass cap. Since the mpu is powered by the arduino, does it need its own cap? Assuming the arduino has one, of course. If so, why the double protection? Should the hc06 get one too?

Thanks,
Kyrle