TimB's Project/Sprint List

This thread will be used to keep track of the various projects I’m working on and to solicit feedback, ideas and suggestions from the community. Certain larger projects may get a thread of their own which I’ll link to.

So, if anyone has questions, comments or suggestions, please feel free to post!

Hardware Projects

  • Core Power Shield [Design Stage]
    Replacement for the current Mustachioed Battery Shield. Featuring: Up to 2A Charge Rate; Integrated Fuel Gauge; Solar Panel Input with MPPT Support. ETA: March 2014

  • SparkBot [Prototyping Stage]
    A small robot with a 5" Circular, Two Level, Expandable Chassis. Designed as an easy to use robotics platform for use with the Core Motion Shield! Features: Two Independent Metal Gear Motors with Wheel Encoders; Front Facing SR-04 Ultrasonic Distance Sensor; Two Sharp Digital IR Proximity Sensors on Sides; One Sharp Analog IR Distance Sensor on Rear; One Basic IR Sensor on Front Bottom for Edge Detection; Built-In 7.4V Dual Cell Lithium Battery Charger; Built-In Buck Converter to Provide 3.3V Power for Core and Accessories.

  • Core Motion Shield [Pre-Design Stage]
    Small shield designed for robotics and motion control applications. Featuring: Control of Four DC Brushed Motors or Two Stepper Motors up to 2A Each; Additional Control of Six Servos; Built-In Support for Two SR-04 Ultrasonic Distance Sensors and Four Sharp Digital IR Sensors; 9-Axis IMU (Accelerometer, Gyro and Compass). The shield will feature a dedicated MCU (MSP430) acting as a co-proccesor to the Core, handling PWM output to the motor controllers and reading data from the distance sensors. The Core will talk to the shield over I2C and have an easy to use library to control motor speed and read sensor data. ETA: Spring 2014

  • Project Cosmos [Pre-Design Stage]
    Wireless sensor pod system. More details soon!

Software Projects

  • Rewrite of the Low Level I2C/Wire Library with DMA Support! :spark:

  • Digole Display Library

  • RSSI/Signal Strength/WiFi Scan Functions for the Network Class :spark:

  • pulseIn Function for the Wiring Class :spark:

  • Twitter Library

  • Full Graphics Library Based on U8glib (Will support a large number of TFT and OLED displays!)

  • Robotics Library

  • Power Control Library

  • Sharp Memory Display Driver

  • Wii Nunchuck / Motion Plus / Classic Controller Library

Bold Items are High Priority; Items Marked with a :spark: are Targeted for the Next Firmware Release


Busy Man!

Don’t forget to add Sharp Memory LCD to the Software Library Projects.

Keep up the good work Tim

Yup, added! That was going to be part of the U8 Library, but I went ahead and added an entry for clarity. :smile:

So I was playing around with the design for the Core Motion Shield and came up with something a bit funky!

Right now this is a three layer board: Top, Ground, Bottom. The ground layer is in the middle of the board and nothing but a 100% solid copper layer. The two motor controller chips (MOT1 and MOT2) are what TI calls “PowerPAD” which basically means that in addition to the pins the bottom of the chip itself also has one large metal pad that’s used like a heat sink. See the large area of copper around the chips? The pads are directly soldered to it. See the holes surrounding the large copper pour? Those are vias connecting it to the aforementioned internal ground plane. So the heat generated by the motor controllers is spread out internally through the entire board! At this point you’ve most likely noticed what appear to be copper dice hanging off the sides of the shield. Internally the ground plan runs through these as well, however there’s also a thick layer of copper on the top and bottom with vias connecting all three layers. These act as sort of “cooling fins” not only enhancing the thermal area of the board but also letting air pass directly through, further cooling the internal Ground/Heatsink plane.

I’ve got several other variations on this design (smaller fins, one giant fin, etc.) that I’m running through some software so I can calculate the optimal configuration for keeping the motor controllers from overheating!

I just thought you guys might enjoy a peak into the design process. :smile:


The Motor Shield looks sweet.

How about some sort of Xbee Shield? I know your working on something similar but I’m testing out the range on these XBee Pro 900 HP with Dipole Antennas and I’m getting .8 mile range which is pretty exciting considering there is about 150 houses and trees with little leaves between the radios. . I just have one board sitting in my front window at home and the second XBee with me in the car hooked up to the laptop running XCTU range test software.

The XBee’s are nice for now and their software is has been updated and is even nicer. I know you could easily draw up a shield that would accept the XBee and drop right down on top of the Spark Core for easy use. Would you be interested in making a shield for the XBee? I will buy some if you are.

Have you heard about electromyography (EMG)? https://www.sparkfun.com/products/11776 …that would be nice shield for Spark :slight_smile: My GF studies a bachelor degree in nursing, so I’m always interested in bioinformatics.

I have. That would be a neat shield to add on to the Motion Control Shield so you could manipulate a robotic arm…with your actual arm! Or imagine controlling a Hexapod with your fingers? (Itsy Bitsy Spider anyone?)

I’ll do some research. Anyone else interested?

1 Like

I’m sure my 4 year old daughter would love to help make and control a robot spider!

I’d love to see a video of that! :joy_cat:

So the idea is you’d have a :spark: with the Motion Control Shield on the Hexapod and another :spark: with an EMG Shield and electrodes connected to your fingers. The latter would control the former wirelessly! I can see embedding the EMG Shield in a glove or gauntlet of some type that has embedded electrode sensors and an onboard accelerometer + gyro. :spark: Power Glove anybody?


Added info on the SparkBot and WiiChuck Projects. The I2C Rewrite is currently #1 on my priority list and I hope to have it out before the next update!

I wonder if a similar approach could be applied to solder in motor terminals to such pads? Giving the ability to solder heavy gauge motor terminals.

timb, this is not critical now, but the more I think about it, the more I like the idea that ALL shields should be using an MPS430! Do you think on an SD type shield, the MPS430 could run a FATFS type core? That would speed up I/O in a big way, lighten the code load on the Spark and could be applied to other mediums like FRAM, SRAM and SPI flash. Since it will be open source and in-circuit programmable, a user could burn any “profile” on the MPS430 for the I/O model that best suits their need. Thoughts?

Yeah that’s totally doable. I can run FreeRTOS and a FAT stack even on the $0.30 MSP430s!

They have a UART and/or I2C boot loader so allowing a user to swap firmware is as simple as uploading a sketch from the WebIDE. Compiled MSP430 binaries are stored in TI-TXT format, which is a text file with hex representing each byte. This is used for flashing from the boot loader. (Think Digole Display bitmap data, store it in a char array in a special sketch and you’re good to go!)

1 Like

I think I just crapped myself from excitement! FreeRTOS with FAT or other stacks would make a fantastic foundation for any shield. Dude, that would blow away any “regular” shield and make the Spark (or any other processor for that matter) fracking fly! I am a huge believer in distributed processing. These days, the cost is not in the hardware, it’s in the software and the more you simplify it, the better. I saw this big time with the Digole display.


I was thinking about this the other day I while it looks cool, it would be more effective to fill in the space between the fins… giving you more cooling surface area. Not to mention filling the area back in is free of charge. Also the more you stitch the planes together the better. The copper area is already plenty sufficient for the current of those drivers, could even be overkill for heat dissipation to have the fins… I haven’t looked at the specs and how efficient the chips are… actually I don’t think you posted it anyway.

timb, I agree with BDub. I did a little research and of course, the more solid planes you have the better. 2oz copper is better than 1oz on the planes and having plenty of connecting vias is good. Having fins won’t do much since the heat will not be dissipated on the edges so much as it is on top and bottom. So solid “wings” would be more effective.

Oh yeah, I know, the more solid area the better efficiency. That particular design provided more than enough cooling for 8 amps of motor control and actually originally stemmed from and idea similar to @mohit’s where each “fin” could act as a motor terminal as well.

So I’m at a weird place with the Motion Shield right now. I’m wondering if I should break the IMU and sensor inputs off into another shield. So the Motion should would only be for controlling motors and servos. Then I could make a “Sensor Shield” with a 9-Axis IMU plus other goodies like a high resolution IR temperature sensor, humidity sensor and other MEMS goodies (which wouldn’t have been included in the Motion Shield) and of course the ultrasonic and IR inputs. The reason I’m thinking of going in that direction is because, for example, the STM IMU I’m looking at is $7 in 1k quantity, which is the entire Motion Shield BOM by itself!

I mean, would you guys rather pay $10 more and have an IMU on your motor shield, or would you rather have it separate?

timb, I haven’t done a lot of robotics yet but it would seem to me that not all motor control projects require an IMU (3d printer, robotic arm, whatever). So I would say the IMU is separate. However, I also think too many vertical shields is unwieldy. You may want to consider a shield of shields or a “bus” shield that could accommodate a Spark and 2 or more shields. It could be made 2x2 (square) or 1x4 (long). :smile:

Which 9-Axis IMU are you looking at?
I just ordered one of these and was considering porting it to spark core:

Also I think a separate IMU shield that is well support is probably a good idea.
Although at some point I would probably build a new PCB with everything on it.

That’s the one I was looking at! It seems a lot easier to use than the IMU-9150.

Most likely I’d have it connected to an onboard MSP430 which would pre-process the data and interrupts, bringing the pin count down significantly. But I’d add some solder jumpers which would disable that feature and allow you to access the LSM9D0 directly if desired.

After thinking about it a bit more, this would most likely be called the “Core Bot Board” or something. I’d still like to make a cheap “Core Sensor Board” that didn’t have an MCU or anything on it that just featured various common other types of sensors, like the aforementioned IR temp sensor, humidity sensor, barometer, photosensor, stuff like that. Something good for prototyping or making a thermostat out of.