I’m going to buck the trend in this forum, and just document a project I’m working on. I’m sure I’ll pose questions along the way, but my main goal here is to give myself some incentive to keep moving forward on this project.
I’m starting to build the successor to a self balancing skateboard I made a few years back. An avid snowboarder, I wanted something to play with during the dry seasons here in Colorado. Plenty of people have made these before, but it seemed like a great project on many different levels. I documented it a bit here: http://teamcosmos.com/skateone/index.shtml. Video here: https://www.youtube.com/watch?v=rhfugvQB1jY. It used a Netduino and a 6 DOF IMU from Sparkfun, amongst other items.
It was a fun project, but as is typical, halfway through the project I was already thinking of the next version of the skateboard. As noted on the above site, there were a few issues that haunted the project: Minimal feedback from the skateboard, a difficult to access micro-controller, and physical layout issues that caused problems turning or climbing hills.
So the upgrade plans involve a few toys from SparkFun: An RGB LED strip that wraps around the skateboard, some bright LEDs for headlights, a Bluetooth module, and an Infrared receiver. I’ll use the LED Strip to indicate things like speed, direction, angle, etc. I’ll dump a lot of data out via the Bluetooth module, and allow modification of key variables via Bluetooth as well. The infrared receiver will allow me to tweak settings when I don’t have a laptop or phone handy.
I’ve been working on version 2 of the skateboard for quite a few months. I’m past the design phase, and am wrapping up the chassis building phase. I’ll do a few quick posts that cover the design considerations and the building, just to catch up to the current state.
In terms of design, as I mentioned before, there were a few items to address:
- **Clearance issues** - I need more clearance, especially while turning.
- **Accessing the Microcontroller** - I want to be able to upload new code easily, without tearing apart the machine.
- **Feedback** - Having a Bluetooth interface would be great in terms of getting debug info out, and tweaking settings without recompiling.
- **Up the Nerd/Wow factor** - While not as dorky as a Segway, I have to admit I'm not 100% comfortable riding this thing in public. I need to up its visual appeal somehow, or conversely make it so overtly nerdy that you have no choice but to truly embrace that inner nerd.
There are other smaller issues to address, such as weight, ease of carrying, etc., but the above issues are the big ones. From a chassis design perspective, really the first issue is the only one that could be addressed. I started playing around with a CAD program, and eventually came up with a layout that I liked. The placement of components is nicer, I lopped off the corners of the foot rests, raised the deck farther from the ground, and improved the bearing setup.
In the following picture, the new skateboard is on the left, the older is on the right.
With the design more or less finalized, I started machining. I have a simple manual mill from Enco, so I can’t do fancy curves or compound angles easily. I started with this pile of aluminum:
[
A month or so later, and 6 pounds of aluminum chips on the garage floor, I ended up with this:
[
You can see the channel running around the outside that will house the RGB LED strip from SparkFun. Now to face some of the electronic and software challenges. While I’ve been building combat robots for years, I’m still pretty weak when it comes to electronics. Part of the appeal to this project is to stretch my understanding a bit in this area.](http://teamcosmos.com/SkateTwo/frameComplete.JPG)](http://teamcosmos.com/SkateTwo/rawAlum.JPG)
- An [[A28-400 Magmotor](http://www.robotmarketplace.com/products/0-A28-400.html) from Robot Marketplace
- An [[OSMC motor controller](http://www.robotpower.com/products/osmc_info.html) from Robot Power
- A [[80 amp contactor](http://www.robotmarketplace.com/products/TW-C1.html) from Robot Marketplace (not pictured)
- Two 4 amp hour 6s LiPo batteries
- A [[Netduino 2](https://www.sparkfun.com/products/11663) from SparkFun
- 4 [[Super Bright LEDs](https://www.sparkfun.com/products/11118) from SparkFun
- A [[LED RGB Strip](https://www.sparkfun.com/products/12026) - Addressable from SparkFun
- A [[6 DOF IMU](https://www.sparkfun.com/products/10121) from SparkFun
- A [[BlueSMiRF Silver](https://www.sparkfun.com/products/12577) from SparkFun
- A [[Pro Micro Arduino](https://www.sparkfun.com/products/12640) from SparkFun
- A [[Infrared Remote Control and IR Diode](https://www.sparkfun.com/products/11759) from SparkFun
- A 10 amp 5 volt DC/DC converter from DigiKey (not pictured)
](https://www.sparkfun.com/products/11759)
There are a few more odds and ends, but those are the big items.
The plan is to use the Arduino to control the LED strips, and the Netduino to control everything else. The LED strip require microsecond timing to control properly, and the Arduino has open source libraries that will do this for you. I’ve played around with custom firmware on the Netduino to try to control the LED strip, but haven’t had any luck. The main issue there is my lack of a good scope, so I can’t troubleshoot my timing issues.
I suspect that the Netduino will be busy running everything else, so offloading some of the work to the Arduino is a nice option from that perspective. I’ll have the two micro-controllers talk to each via a serial interface.
Lyndon: Yeah, the 4.5 HP is overkill, but I had a few of these motors laying around not being used. You’re right on the money with the weight, I’m hoping for about 25 pounds. The motor is a large contributor to the overall weight.
Codlink: I know what you’re talking about. I wanted to build one of these for about 5 years before I finally got around to it.
I’ve been sneaking in a few hours here and there to get the electronics mounted.
Here you can see the batteries, contactor, two power switches, the 5 volt DC/DC converter, and the Netduino 2 (unmounted). One switch is a momentary switch to turn everything on and off. I’ll use the Netduino and a transistor to keep the contactor on after the momentary switch is pressed. That way I’ll be able to turn the skateboard off via software. For example if someone stopped riding it without hitting the switch again, I’ll be able to determine inactivity and power everything down.
The second switch is an inline SPST that will disable the contactor physically. You never know when something will catch on fire, or you have a bug in the software that won’t allow you turn the electronics off in a timely manner (usually discovered when the skateboard is on fire).
Here’s the motor and OSMC installed and wired up. I still haven’t run a cable from the OSMC back to the micro-controller. I’ll do that once I have the micro-controller mounted and the custom shield installed.
Next is a picture of the contactor, batteries, switches, and DC converter wired up. It’s turning into a bit of a rat’s nest, I’m sure I’ll have to move wires around to get everything happy in there. In the background is the Netduino with a custom shield for the original skateboard. It was test run to see if I could get a much simpler board printed without missing anything. It’s the first one that I’ve done, I wanted a little practice before the much more complex shield that I’ll be using on the new skateboard.
I imagine progress will slow down a bit at this point. The next big thing to do is finish the design of the Netduino shield. I have a first pass done, but need to go back and make a few changes, double check what I did a few months ago, etc. As I go through that process, I very well may post some questions. I’m a almost a complete newb when it comes to that kind of stuff.
Thanks! I hope to someday add CNC capabilities to my mill, it’d open up a lot of design possibilities. As it is now, I spend a lot of time planning everything out, doing setup, using a belt sander for outside curves, etc.
Since my “practice” board showed up in the mail that I had made for the original skateboard, I took a slight detour and have been getting it into the old chassis.
The original board is to the right, the new board is on the left. A much cleaner look.
I’m still working out the kinks, the IMU is oriented 180 degrees differently. It’s also given me the opportunity to mount the board better in the frame, so I can actually plug a USB cable in while the microcontroller is in the skateboard. This allows me to get some output via the debugger while the skateboard is on. So now I’m playing with the original code, tweaking things here and there.
Unfortunately I introduced some kind of power issue, the code exceptions here and there, unable to read the IMU. Not sure if I have a cold solder joint somewhere, or if I damaged the IMU or microcontroller board in the conversion process.
I’ll keep playing with this until the original skateboard is up and running. Then I’ll switch back to the new project. At the very least I proved I can layout a very simple board, I’ll have a bit of experience to apply to the newer, more complicated board.
I’ve been futzing around with controlling the LED strips via an Arduino. My original attempts at controlling the LEDs with the Netduino involved a few custom firmware experiments that never panned out. After a few hours of playing with the Arduino, I got the basics working in a few hours.
I plan on offloading all lighting duties to the Arduino, but keep the Netduino as the master controller. I just prefer working in C#, and the Netduino IDE is much nicer.
After a few frustrating days of trying to get the two microcontrollers to talk over serial, I realized that my original Netduino board was causing various issues. Swapping it out to a newer board cleared up all the inconsistent behavior I had been seeing. Very frustrating, but I should have known better, as the first board had given me trouble in the past.
Here’s a short video of the LEDs working. I’ll have to be careful, it’d be easy to spend weeks coming up with interesting animations. Click on the photo to watch the video.
I’ve run into my first head-scratcher, and could use some help. As a reminder, I’m fairly a noob when it comes to electronics, some of the basics are very confusing to me.
This only happens when I add a voltage divider into the circuit, and I’m powering the circuit from both the USB cable and a battery. Once I add the voltage divider in, I have a problem reading data from the IMU.
My question relates to how I have everything grounded. I have a 24 volt power bus, a 5 volt bus, a 3.3 volt bus, and often have a USB cable plugged in as well. The 24 volts come from the battery, the 5 volts come from the DC/DC converter, and the Netduino steps the 5 volts down to 3.3v, which is used by a few other devices (IMU included). The USB cable is also supplying power to the circuit.
Should I have all these buses sharing a common ground? I always understood that to be the case, but could be wrong.
The voltage divider is stepping the 24 volts down to a 3.3v signal for a Netduino analog input. Even if I remove the jumper to the Netduino, simply plugging the 24volts into the divider will cause the IMU to fail.
I seriously doubt that the voltage divider causes any kinds of voltage sag, but somethings definitely going on. Some times after plugging it in things will fail right away, other times it takes a minute before things go wrong.
I don’t have a scope, so I can’t get a good idea of what’s happening voltage-wise.
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.
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.
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.
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.
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++.
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.
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…
http://teamcosmos.com/SkateTwo/SkateOne.JPG
