SparkFun Forums 

Where electronics enthusiasts find answers.

General project discussion / help
Did you make a robotic coffee pot which implements HTCPCP and decafs unauthorized users? Show it off here!
By satacoy
#176768
I reorganized the wiring and components a bit on the breadboard, and the strange voltage/ground problem went away. It's kind of like when you can't find your car keys, maybe it's time to start cleaning up the joint. I suspect I had a ground loop somewhere non-obvious.

Here's a bit of video showing infrared and Bluetooth communications working.

http://youtu.be/fZSd1P348A8

I have run into a few interesting problems. One issue was related to serial communication with the Arduino. Since the lighting code is so timing sensitive, it disables interrupts while it's writing data to the LED strip. This is problematic as it means your serial data will be dropped on the floor if you send any while the Arduino is writing to the LEDs.

I tried a few methods to get around this. I settled on having the Netduino set a digital output to high, which signaled the Arduino to stop refreshing the LEDs. Due to timing issues, I have to wait a little bit after I set the output high, write out the data, then wait a few milliseconds before signaling that it's OK to start refreshing the LEDs.

A better solution would be to have the Arduino handshake with the Netduino when it was ready to receive data. I don't want to use up too many pins, so I'm OK with a few wasted milliseconds.

The disabling of interrupts also made uploading new code to the Arduino touch-and-go. I typically had to cycle the power to the Arduino in order to get a new sketch uploaded.

I also got a voltage divider and the IMU prototyped in. I'm planning on using the voltage divider to warn me when the batteries get low. I borrowed all my IMU code from the first skateboard, and seem to be calculating a pretty good approximation of pitch angle.
By satacoy
#177018
Progress continues. I've refined the software a bit, and have the battery indicator, angle display, and a few other aspects of system working.

This weekend I drew up the plans for the circuit board/shield, and have shipped it off to be manufactured. It's much more ambitious than my simple shield for the first skateboard. I was in a bit of a hurry, so hopefully there are no fatal mistakes.

Image

It'll take a few weeks to show up. In the meantime, I'm hoping to flesh out the rest of the software and get the last few mechanic changes in place. I still need to mount the Netduino, figure out where to place the BlueTooth module so that I can get reception, secure the wiring to the frame, etc.

Probably not a lot of posts until the board shows up in the mail.
User avatar
By Ross Robotics
#177029
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++.
By satacoy
#177030
The shield is available here:

http://123d.circuits.io/circuits/236244 ... two-shield

I can release the software once it's complete.

I always prefer discussion on specific topics, rather than just saying "Here's my code/design". Many times people will grab the code/design, try to figure out why you did specific things, then make assumptions. In that case there is no searchable knowledge on why decisions were made. Discussion contributes a bit more to the overall community, IMO. But, I'm fine with either approach.
User avatar
By Ross Robotics
#177045
I really don't know what to ask until I can see the software.. Then I may have questions. But usually I can figure it on my own. I wouldn't expect you to release anything until the bugs are out and you have a fully functional project..
By satacoy
#177466
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.

Image

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

Image Image

Much tidier than the prototype:

Image

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
By satacoy
#179663
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.

Image Image Image

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.
By satacoy
#179686
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!
By Mee_n_Mac
#179688
Almost sounds like forward and reverse were on at the same time. That'll short the H bridge and smoke it real quick.
By satacoy
#179691
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.
By lyndon
#179701
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?
User avatar
By Ross Robotics
#179708
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.
By satacoy
#179869
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?
User avatar
By Ross Robotics
#179872
Jumpers resistance? Have you measured with and without the jumpers?