Self balancing skateboard

Community Projects
21

I finally received the circuit board in the mail on Friday. It looked good, but having it in person made me realize that the holes for the Pro Micro daughterboard were too small. That was odd, as I’d used a pre-made template that I found. I guess whoever designed that template had used tiny connectors, standard .100" headers were much too large.

[

I eventually found a set of pins that were small enough to work, and got everything soldered together.

[ [

Much tidier than the prototype:

[

I haven’t fully tested it yet, but it doesn’t release the magic smoke when I plug in a USB cord, and everything appears to be getting power. Next up I’ll get it mounted in the frame, and start running necessary connections to it.

Pete](http://teamcosmos.com/SkateTwo/IMG_2942.JPG)](http://teamcosmos.com/SkateTwo/IMG_2970.JPG)](http://teamcosmos.com/SkateTwo/IMG_2969.JPG)](http://teamcosmos.com/SkateTwo/IMG_2967.JPG)

22

The holidays, the flu, and other projects have consumed a few months. I’m finally making some progress again on the skateboard, although there have been a few setbacks too.

First, I built a external sensor pod for the Bluetooth module and IR receiver. Testing a few plastics I had laying around, UHMW seemed to allow both Bluetooth and IR signals through. The plan is to mount this module externally on the frame, location to be determined.

http://www.teamcosmos.com/SkateTwo/IMG_2956.JPG http://www.teamcosmos.com/SkateTwo/IMG_2958.JPG http://www.teamcosmos.com/SkateTwo/IMG_2961.JPG

I did spend a good amount of time on the software. I’d gotten it to the point where the skateboard should theoretically self balance. I thought I’d do some tests with the wheel free-spinning (no chain). I should have done a bit more testing before I did this, as there was a bug that caused some very erratic motor behavior. Full forward to full reverse type of behavior. This ended up frying the OSMC board pretty good. Magic smoke, very nasty odors, etc. Luckily the rest of the electronics survived unscathed.

As a result, a lot of my time has been spent learning more about this controller so that I could repair it. About $40 worth of FETs and various other components later, things seem to be running again. I’ve tested it with a smaller motor, with very controlled speed ramping, and all is fine. I’ll do a few more tests with the larger motor, refine my control algorithm, and try again. One very real fear is that this motor controller is not up to the task of controlling this motor. Reading through the OSMC archives, it seems as if things should be OK, so hopefully it’s just a matter of refining my algorithm and avoiding unrealistic forward/reverse cycles.

23

Well, that was short lived.

I rewired things and let the test code cycle from full reverse slowly to full forward, pausing at 100%, 0%, and -100% throttle for 5 seconds. Something wasn’t quite right at the full forward/reverse states, the motor would pulse strangely. After a few cycles of turning things off, feeling for heat on the FETs, and trying again, two legs of the hbridge exploded. So I’m out at least 8 FETs, possibly another controller chip.

Back to the OSMC group to see if I can figure out what I’m doing wrong, or what additional components may be problematic.

So close, yet so far!

24

Almost sounds like forward and reverse were on at the same time. That’ll short the H bridge and smoke it real quick.

25

The OSMC uses a hbridge controller chip that won’t allow you to do that. Thank goodness, or I would have fried many other board. There’s something a bit more subtle going on here, unfortunately.

At this point, my best guess is that another component on the board is fried. Many of the components can’t be tested without first removing them from the board, and several of those components are surface mounted. I didn’t do a thorough job of this after the first failure. I was certainly optimistic when the rebuilt controller was able to control a motor drawing several amps without problems.

I’m looking at this a grand learning experience. I’m still willing to tear this thing down and rebuild it many more times before I give up and just buy another controller.

26

Mee-nn-Mac may be right. Remember that while the controller may have logic to prevent both sides of the bridge being commanded on at the same time, it does take time for the transistors to turn off and current to drop to zero. So you may have one side told to turn off and the other on. If it switches on before the current in the (turning off) other side dissipates, you will still get shoot through current that can blow up the bridge. This seems to be a possibility especially since you said it worked for a few seconds then went south.

Is there a dead-time setting for the H-bridge control?

27

codlink:
Thanks for the update. Curious, are you going to release the software and hardware files once completed? Not that I am going to duplicate your project, but I would like to look at your software as I am trying to teach myself C++.

The best C++ book I know: http://www.amazon.com/The-Complete-Refe … 0072226803

28

Thanks for the link. I don’t have that book, and after a few minutes of searching, I found a PDF of it for free. It’s now in my CPP reference folder. Although I do have several C++ books, I learn best by hands on.

29

This is really getting strange, and well past my knowledge level.

I got the OSMC running again, set up a test program to spin the MagMotor at 50% for 5 seconds, turn it off for 5 second, run in reverse for 5 seconds, etc.

The speed controller wasn’t catching on fire, but was getting pretty hot. That was odd, as I was spinning the motor no-load, and should have been pulling a fraction of the current the controller can handle. I’d tested and retested the components on board, and am pretty confident they are good.

At some point I tried another MagMotor, same model. It ran fine. Ah Ha! I thought. I was simply using a bad motor.

So I took the old motor out, disassembled and cleaned it, retested, and it too ran more smoothly, and without heating the controller. Sensing victory, I put the new motor in the skateboard, soldered new connectors to it, wired everything up and tested again. Right back where I started. Rough running motor, and hot FETs.

I thought that maybe by bolting the motor into the frame I was binding the motor up a bit. Maybe cleaning the old motor didn’t solve the issue, but pulling out of the frame did. The other possibility was that it wasn’t a frame/binding issue, but the fact that I had to use jumper wires between the motor controller and the motor when the motors were out of the frame.

To test that theory, I left the new motor in the frame, but instead of directly attaching it to the controller, I used the 50cm jumper wires between the motor and the controller. Sure enough, the problem went away. Once I removed the jumper cables, the problem came back.

If I only eliminated one jumper cable (say from motor negative to controller negative), the problem popped up. That was the case regardless of which jumper cable I eliminated.

I thought that maybe the alligator clips on the jumpers were getting a better connection than the bullet connectors themselves. So I resoldered the bullet connectors, making sure to get a good connection. That didn’t help. I used steel wool to clean up the connectors, no dice. When using the jumper cables, I was going directly from bullet connector to bullet connector, so it wasn’t like I was using a completely different path to the controller.

The jumper cables I am using are the SparkFun 50cm cables. They are a tiny gauge, I actually doubled them up because I was concerned that I’d melt them, even just pulling <10 amps. They don’t get hot, but magically make the issue go away. I can tell the motor is running faster and more smoothly with them on, it’s pretty obvious just from the motor noise.

Any ideas? Why would replacing a short high current capable connection with about 2 feet of low current cable make a difference?

30

Jumpers resistance? Have you measured with and without the jumpers?

31

Have you tried running it at about 10% with the normal wiring? How does it run then?

32

It’s a bit difficult to measure, as the wires go into the motor, and I don’t have great access to the other end. It would be an interesting number to see. I’m sure the thinner wires are providing more resistance, I just don’t know how much, yet.

Any ideas on why having more resistance would cause things to behave more properly? That’s the part I’m struggling with.

33

I assumed your motor driver allowed you to control the current sent to the motor.

My guess is that with the correct wiring your motor is consuming a huge amount of current at startup and the voltage of the batteries is drooping. If the voltage droops, then the controller can no longer drive the output FETs into full saturation, so they are acting as voltage-controlled resistors and dropping a lot of power and getting hot.

Here’s an experiment you can run: start the motors up with the thin jumpers that are making it work “correctly.” Once the motor is up to speed, short out those jumpers with the beefier wires. If it continues to run smoothly, you have a power supply problem. If it begins to bog down and the controller FETs get hot again, measure the voltage at the batteries. I’ll bet dollars to donuts that the voltage will be well below what you expect.

34

Thanks for the guess. I’ll give this a shot tonight.

I’ve seen this kind of issue in the past when using crappy batteries. In this case I’m using batteries that are advertised as producing 80 amps continuous, and I have two in parallel. I should be drawing well below that in this no-load situation. But, as I continue to pull my hair out, I’m willing to try anything.

I’m also planning on soldering up some beefier jumper wires to see if the gauge of the wire makes any difference. That’s pretty similar to what you’re suggesting, although I like the idea of eliminating the thinner wires after things are OK.

35

Oops, when I mentioned that “it’s a bit difficult to measure”, I was actually replying to Codlink’s reply, didn’t see your post sneak in there.

I ran a battery of tests tonight. I did measure the voltage at the battery as the motor spun up. They started at about 24.05 volts, and never dropped below 24.00. Thinking about it a bit, I should have used the “minimum” setting on the meter, in case the voltage was dropping very quickly, then equalizing. I’ll try that next time. Again, I’m pretty confidant that the batteries can handle the ~10 amp draw all day long without sweating.

I tried the suggested experiment. I started with the thin jumpers on, let the motor spin up, then used a much beefier jumper to connect the two. There was a slight change in sound coming from the motor, but nothing significant. I tried doing the full spin up/down cycle with the beefier cables, and they too sound much better than directly connecting the motor to the controller. The thin set of cables is probably 20 gauge or smaller, the beefier cables are 12 gauge. While there’s a slight difference when testing with either set, they both offer much better behavior than the direct connection method.

I busted out the hand-me-down oscilloscope, and measured the output at both the motor and each leg of the hbridge. I’ve been waiting years to put this thing to use.

The output at the motor looked like this. The left image is without the motor attached, the right is with the motor attached to the controller.

Scope-Motor.jpg800×300 57.4 KB
http://teamcosmos.com/SkateTwo/Scope-Motor.jpg

The measurement at the legs of the FETs were more interesting. The top two images show what the switching waveform of the leg looks like. The left picture is again without the motor, the second picture is with the motor on. The motor is definitely throwing some interference of some sort in there, but it’s not too significant.

The bottom two pictures are the waveform when the leg should have been fully on or off (It looks like I took the picture on different legs, but you get the idea). The left image is with the motor attached directly to the controller. It’s a very noisy signal, it should be a flat line. The right image is with the thin cables attached. It’s much cleaner.

Scope-Leg.jpg800×600 103 KB
http://teamcosmos.com/SkateTwo/Scope-Leg.jpg

I also tried several different PWM-ing frequencies. I tried much lower (1 khz), which kept the board cool, but was very loud, up to 16khz, which was less noisy, but heated up the FETs seriously, and still didn’t sound “right”. I typically run at 8 khz, which is what the previous skateboard used with no issue with the same motor (but different controller).

I’ll keep troubleshooting the board, it does seem like something is fundamentally wrong with it.

Pete

36

After a bit more trial and error, including replacing a few more parts of the motor controller, I tracked the problem down to interference between the signal cable and the motor brushes. Due to the physical layout of the skateboard, the signal cable snakes right near the end housing of the motor, right where the four brushes are. Moving this cable away from the motor makes things run much more smoothly.

I should have known better. Brushed motors are notoriously noisy. This motor has suppression capacitors pre-installed, so I didn’t think much of it. However, it’s obviously not enough in this case.

Any suggestions on how to best shield the cable? I can reroute if necessary, but that will cause it to run near the chain and pulley. I can just see it getting sucked into the drive mechanism, so I’d like to avoid that if possible. Will something as trivial as tinfoil work, or do I need to get more science-y?

Pete

37

What signal is it interfering with?

It might not be electrical noise. With the amount of current that motor is using, the magnetic fields may very well be inducing a current into the signal line; only way you’re likely to improve things if that’s the case is by moving the wires.

If it really is just noise, then shielded cable isn’t expensive.

38

What I’m calling the “signal cable” is the cable that runs from the micro-controller to the motor controller. It’s a ten wire ribbon cable, several of the wires are held either high or low, and two of them are PWM’d at 8khz. I was guessing that the motor was interfering with the PWM signal which controls the switching of the MOSFETs.

If it’s a magnetic field, it’ll be rough to avoid, as the cable has to run past the motor regardless of how I route it. It’ll either have to go by the front or the rear of the motor.

I’ll play around with placement. I’ll try a shielded cable too, if I can figure out how to get the right 10 pin connector attached. My rough understanding of shielded cables is that the shield is grounded. Is that correct? Or is the shielding just a metallic material?

39

Correct. Best practice for shielded cable has the cable grounded at one end.

40

Following up on my last post [this guy is pretty knowledgeable about motor controllers and current line of thinking is to ground digital shields at both ends and analog control shields at one end. His post is pretty interesting.](http://www.practicalmachinist.com/vb/robots-automation/vfd-power-cable-shield-grounding-question-299703/#post2495602)