Skip navigation

Upcycle It

9 Posts authored by: Andy Clark (Workshopshed) Top Member

After discounting the transistor based H-Bridges in the original car, I started experimenting with the TB6612FNG module. Despite its small size, it should be able to easily to take the few hundred mA needed for the motors.

TB6612FNG

My first experiments with this were not successful, every time I hooked up the motor supply connector the current shot up and the supply voltage collapsed causing the Edison to reset. After a few hours of double checking all the wiring and general frustration, I swapped to using LEDs to determine if my code or wiring was at fault. This worked fine with the direction LEDs turning on and off, and the PWM one fading on and off. I did get caught out by the fact that not all pins support PWM but you can swap those with the "swizzler", a set of header connectors that I've not quite worked out yet.

Testing with LEDs

var mraa = require('mraa');
console.log('MRAA Version: ' + mraa.getVersion());

var pwm = new mraa.Pwm(6);  //PWM available on default swizzler positions. (3,5,6,9)
var forwards = new mraa.Gpio(7);
var backwards = new mraa.Gpio(8);
forwards.dir(mraa.DIR_OUT);
backwards.dir(mraa.DIR_OUT);
var dir = true;
var value = 0.0;
var step = 0.01;

pwm.period_us(700);
pwm.enable(true);

toggleDirection();

setInterval(function () {
    value = value + step;
    if (value <= 0 || value >= 1) {
       if (step <= 0) {
            toggleDirection();
        }
        step = -step;
    }
    pwm.write(value);
    } , 50);

function toggleDirection() {
    forwards.write(dir?1:0);
    backwards.write(dir?0:1);
    dir = !dir;
    }

process.on('SIGINT', function () {
    console.log("Shutting down SIGINT (Ctrl-C)");
    pwm.write(0);
    forwards.write(0);
    backwards.write(0);
    process.exit();
});

 

After success with the LEDs, I tried a second H-Bridge module (from a different supplier). That did not have the same issue so I concluded the problem was with the first board which is now discarded.

 

 

Power supply

Given the motors are the main power drain being about 300mA each, I was looking for a supply that could supply about 1A, was light, easily recharged, had capacity for a few hours play and was in around the 5v - 9v range. Despite having a range of different battery boxes and rechargable batteries I did not have anything that met those requirements. I also had a small 6v lead-acid battery but that was very heavy. Finally, I looked at buying some RC car batteries but these were very expensive and I'd need a charger too.

 

Then I realised that I did have a phone "power bank" that I'd won in a prize draw the previous year.

Power Bank

 

Capacity: 4000 mAh

Output: 1A

Input/Output Voltage: 5V

Battery Type: Rechargeable Li-Ion

Charging time (to charge power bank): Up to 4 hours

Standby Time: Up to 4 months

That should be perfect, so I doctored a USB cable so I could attach it to my breadboard. Unfortunately my cables were not coloured coded as per "standard" but I worked it out with a multimeter. The battery box happily powered my test LED and also the motors.

Motor Test 1Battery Test 2

 

Reference

TB6612FNG Hookup Guide

Power Consumption for Intel® Edison Board for Arduino*

Power Banks | My Doodles

Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

[Upcycle It] Interactive Race Car Driver - Car modification

[Upcycle It] Interactive Race Car Driver - Furby Hacking

I'm not quite sure when I bought the Furby but I do remember the Furby Autopsy website inspiring the purchase. So that suggests it was perhaps after 1998.

toetag2.jpg

When I recently checked there are some others that have also done some investigations including puppeteers and universities. A big thanks to Kelly Heaton for giving me permission to re-use her image showing the key parts of the Furby. As you can see there are loads of switches and sensors all over the Furby, there are also lots of moving parts but those are all run from a motor and cam mechanism.

 

Furby Anatomy

minor_Furby_anatomy_HQ.png

Furby Anatomy: From Kelly Heaton - anatomy of the furby

 

All I can say are that the original designers from Tiger Electronics were absolute wizards. They also did not skimp on construction with all the key components being attached via plugs and sockets. The "brains" of the operation are 2 boards with black blobs, it looks like one is a controller and the other is for processing the sounds. There is also an Eprom, Microphone and pre-amp and IR communications.

Schematic.png

Schematics created by Chris Brown.

 

The motor seems to be controlled by a transistor based H-Bridge to the one I found in the RC car, so I think that I'll be swapping that out with a module again. To control the motor I also need to be able to count the pulses from the optical sensor and monitor the home switch. I think there's a couple of errors around this part of the schematics, the H-Bridge seems lopsided and the sensors on the gear position seem to be reverse. However they have saved me a whole load of work and I should be able to hook in my circuits to the connectors where I'll be removing the controller and sound chips.

Motors.pngMotor Sensors

Equally helpful, the team at Northwestern University Mechatronics Design Laboratory have mapped out the Encoder Pulses for the different kinds of motion.

Number of pulses relative to the home position

Pose of the Furby

0 to 30

ears up, eyes open, mouth closed, not tilted

30 to 60

ears down, eyes open, mouth open, not tilted

60 to 100

ears down, eyes open, mouth shut, not tilted

100 to 130

ears down, eyes shut, mouth shut, tilted

130 to 170

ears up, eyes shut, mouth open, not tilted

170 to 200

ears up, eyes open, mouth open, not tilted

Note:

The encoder generates about 200 pulses per revolution of the motor and the number of pulses goes back to 0 again after one complete revolution.

The motion of the Furby is continuous and there the poses described above are just approximations. In many cases, the eyes or ears are partly open or closed.

By looking at the mapping above, however, you can have a rough idea of which number of pulses corresponds to which pose.

The comment "The motion of the Furby is continuous" does seem to tally with my experiments on the drive motor h-bridge which suggest that the motor does not have a stopped option. As per the maindrive my plan is to use a TB6612FNG module for the Furby motor, I'll use transistors to turn on and off the signals to the module.

 

Inside the Furby

I removed the casing and the speaker assembly and that allowed access to the PCB. I disconnected all of the sockets and extracted the board. Using some desolder braid I carefully removed the two "COB" (chip on blob?) boards. I wanted to keep the main PCB operational as that had signal conditioning and a driver for the opto-sensor for the main drive motor.

 

{gallery} Inside the Furby

Inside the Furby

Furby Guts: Inside the back of the Furby

Mechanics

Mechanics: Main drive gear and cams to activate the movements

Situp

Situp Plunger: This plunger causes the Furby to tilt forward

Home Switch

Homing Switch: These contacts are closed once per rotation

PCB

PCB: Note the after production modifications, LED for the optical sensor top left, the 2 daughter boards for control and sound, and the black circle bottom left is the tilt switch

PCB underside

PCB underside: The black and white wires connect up the power connection

Battery Compartment

Battery Compartment: Looking at the battery compartment as a place to put the Edison and a battery

Brain Removed

Brain removal: With the two daughter boards removed there might be space for the Edison in the main housing

 

I wanted to understand the optical sensor as that would be needed to determine the positions for the animations. I realised that the LED on the PCB sticks into a tube and the sensor must be at the other end of that. There's some Schmitt triggers on the output of the photo transistor so we should get a clean signal from that.

 

As per the car, I also wanted to check that the motor was running and the mechanism was working, so I hooked up the motor directly to a 5v USB from a powerbank. The circuit diagram has this running from 6v so I wanted to be sure it would run correctly from 5v, which it does.

 

 

The next thing to do for the Furby is to hook up a H-Bridge and the two sensors to the Edison to check it can be controlled. Some of the other furby hackers have reported problems with the signal from the optical sensor.

 

Reference

Furby Autopsy

Furby-hacking-101

Puppet studio - Furby

Northwestern University - Mechatronics - Furby Dissection

Anatomy of the furby

 

Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

[Upcycle It] Interactive Race Car Driver - Car modification

My main concerns about the car were the high driving position and general space for the electronics. There were some handy screws on the front and back so I though those would make good points to attach my own platform. There is also a bit of flex in the chassis now so my additions will need to include re-enforcement.

 

{gallery} Car Modifications

Before

Before: The car base

Step 1 Remove Battery Box

Step 1: After removing the battery box the platform was still quite high

StrippedDownCar.jpg

Stripped: So I stripped it down even further

Lower driving position

Driver: New lower driving position

Edison on Car

Edison: There should be space in the engine compartment for the Edison

 

Disaster and repair

Although I'd previously thought that the gearboxes were fine, I noticed that one of the wheels was freewheeling whereas the other side turned as a pair. I opened up the gearbox again and spotted that one of the pinions was rotating freely on it's axle. When I removed it, it split into two.

BrokenPinion.jpg

I looked through my collection of gears and found a replacement, except it was connected to another gear. I sawed it off with a junior hacksaw and it fitted onto the spindle. It was a little loose so I added some cyanoacrylate adhesive (superglue).

 

New GearGearboxIn place

Now my vehicle is back on the road and ready for some new electronics.

 

Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

Motor investigation

Before committing too much time to the car, I wanted to check over the motors. The key things to look at were ensuring they rotate freely and to determine the correct motor voltage. Because the motors are sealed it's not possible to check much else such as brushes or bearings. I have taken these kind of motors apart before but I did not want to risk being in the situation of not being able to put them back together.

Motor.jpg

I started by disconnecting the RC controller board so the motors could be tested. The coil resistance was approx 4Ω so I knew I'd need to be careful about limiting the current. Looking at the board the capacitors were all rated at 10v so I suspected this was powered from two or three old style  batteries e.g. 3v or 4.5v. So I started with my power supply set to 2v and 300mA. The motor turned and did not take a lot of current so I increased to 3v and took a reading.

Motors (3).jpg

I tried to measure the stall current of the motor but it went over 1A and I was not comfortable setting my current limit any higher as I did not want to burn out the motors. I did, however, measure the motor under load and it took 600mA. This will be important when I look at the supply as I'll need to have something that can provide these kinds of currents.

 

After re-assembling the car I ensured that both motors worked in both directions and the wheels turned. I'll likely open up the car chassis a little so that I can get to the wiring without having to keep unscrewing everything.

 

Driving the motor

I had thought about using an off the shelf H-Bridge module based on the L298. However looking at the RC board it divides easily into 2 halves for the radio and the power to the motors. I guessed that the latter is two, 6 transistor based H-Bridges.

 

RC Board Reverse Engineering

To reverse engineer the board, took a photo and blew up the print. Normally I would use any chip on the board to determine where the power supply lines are located but the numbers drew a blank, the name on the top is a toy manufacturer. So I followed the electrolytic capacitors instead, also the screws are typically in the ground plane. The transistors were easily identifiable as C3279 (NPN), A1015 (PNP) and A1300 (PNP) the resistors were mostly 1K and 100R. I had big pads for the motors.

CircuitAndPCB.jpgHBridge.jpg

Simulation

The circuit seems to have promise but I was a little concerned that I did not fully understand the circuit, so I opened up Circuits.io to simulate it.

Circuit.png

LHigh.pngRHigh.png

With one input high and the other low the circuit worked as I wanted it to. The motor turned in each direction.

If I took both inputs high then it seemed not to switch off, staying with which ever direction had previously been selected.

If I turned both low then my worst fears were confirmed in that the circuit did not properly turn off the transistors resulting in the current limit being hit and the supply voltage dropping.

BothLow.png

I wondered if there was anything specific about the combination of my transistors that might cause it to work differently to the simulation. My final experiment with the simulated circuit was to drop the supply voltage down to 1.5v. This worked better but the current draw for both inputs low was still quite large at 350mA.

 

Simulated circuit - https://circuits.io/circuits/4643484-h-bridge

 

Testing

Testing.jpg

I removed the RC chip and wired up a spare motor to the H-Bridge. I set the voltage to 3v and the current limit to 100mA. It behaved exactly the same as the simulation, when the motor was running it was fine, when the inputs were all low then the current limiter kicked in.

 

My conclusion is that the motors perhaps never stopped, the controller could have kept them running all of the time. I'd like to be able to stop my motors so it's back to my initial plan of using an off the shelf module, I've got a L298 with a big heat sink and a smaller TB6612FNG module. Both of these will run from 3-5v and logic levels at similar levels. The motors and gearboxes seem to be fine so otherwise the car is good to use.

 

Reference

https://www.sparkfun.com/datasheets/Robotics/TB6612FNG.pdf

https://www.sparkfun.com/datasheets/Robotics/L298_H_Bridge.pdf

http://www.micromo.com/technical-library/dc-motor-tutorials/motor-calculations

 

Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

As mentioned previously my daughter helped me assemble the Edison and Arduino breakout board.

Edison

Installation

I followed the Getting Started with the Edison guide for Win32. The drivers download page suggested that the drivers were only for 64bit Windows but installed just fine, as did the FTDI drivers. However when I ran the setup the Intel Edison Setup application it seemed to remove those drivers and replace with some others. Once the new drivers were installed I picked the option to download and install the latest firmware.

VersionsDownload

We named the board "Eddie", enabled SSH and connected up to the Wifi. Once the board finished and rebooted I checked I could ping

Eddie.Local

Ping Eddie.local

I also checked we could connect with SSH and login as root, using Putty. Once in I double checked the version.

 

root@Eddie:~# cat /etc/version
201606061707

 

I checked for newer software from the repositories with:

opkg update
opkg upgrade

 

It upgraded mraa and upm which connect up the hardware so that's probably a good thing.

 

Prerequisites

Node and MQTT are the main components I needed installed, I checked node using

 

node --version

 

That came back as v4.4.3, that's not the latest so looking at how to upgrade that might be a good idea.

 

I also checked mosquito was installed using

opkg info mosquito

 

Given that mosquito is installed, I'll swap to that rather than Mosca which I've been using for testing.

 

Quick test with MRAA

I mashed together a few articles to get myself a blinking LED on D7 on the grove shield

 

#!/usr/bin/env node
var mraa = require('mraa'); 
console.log('MRAA Version: ' + mraa.getVersion()); 

var led = new mraa.Gpio(7); 
led.dir(mraa.DIR_OUT); 

var ledState = true; 

setInterval(function () { 
 led.write(ledState?1:0);
 ledState = !ledState;
}, 1000);

 

Then I put together an example for using the input and an interrupt.

 

#!/usr/bin/env node
var mraa = require('mraa'); 
console.log('MRAA Version: ' + mraa.getVersion());

var button = new mraa.Gpio(5);
var led = new mraa.Gpio(7); 

var ledState = true;

button.dir(mraa.DIR_IN);
led.dir(mraa.DIR_OUT);

button.isr(mraa.EDGE_RISING, function () {
 led.write(ledState?1:0);
 ledState = !ledState;
});

setInterval(function () {} , 1000); //Do nothing, stops the apps exiting

process.on('SIGINT', function () {
    console.log("Shutting down SIGINT (Ctrl-C)");
    button.isrExit();
    led.write(0);
    process.exit();
});

 

Reference

https://davidwalsh.name/nvm

mosquito

https://wiki.openwrt.org/doc/techref/opkg

mraa: Intel Edison

https://github.com/intel-iot-devkit/mraa/tree/master/examples/javascript

https://software.intel.com/en-us/node/562029#Digital_outputs

https://gist.github.com/george-hawkins/632bad44aa47d528a0eb#file-node-js-mraa-isr-md

Exploring Edison - Mraa GPIO

 

Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

Looking at my overall objective for the challenge I've broken down the work into some steps.

 

  • Motors testing
  • Furby testing
  • Lighting
  • Power supply
  • Driving motors
  • O/S and prerequisites
  • Playing sounds / speech
  • Activating the Furby
  • Software

 

Motors testing

Review the car motors to see what voltage and current they require. Ensure that the car platform still works.

 

Furby testing

See how the Furby is put together, look at controlling the main drive motor and reading sensors. Look at the speaker to see what we need to drive that.

 

Lighting

For the car lighting, look at what we need to drive some LEDs for the headlights, indicators and brakes. Assemble sub boards that can be plugged into the grove connectors to power them. If I have time I'll take the suggestion from Jason and implement the light sensor so that the headlights can come on automatically.

 

Power supply

Review the Edison's power requirements, add to that the various motor and LED requirements. Ensure we have a battery that is capable of providing the voltage and current demands and has sufficient capacity for a reasonable run time.

 

Driving motors

Connecting the motors up to the H-Bridge, controlling speed and direction from the Edison.

 

O/S and pre-requisites

The system relies on some form of operating system to host the software so time will be needed to check versions, ensure I've got Node and a MQTT broker running and hook it up to the Wifi.

 

Playing sounds / speech

Getting the sound card connected to the Edison, reading files from the SDCard and playing them through the headphone connector. Connecting that up to the Furby speaker and reviewing if it will need an additional amplifier

 

Activating the Furby

Getting the Furby controlled from the Edison.

 

Software

Controlling the hardware, looking at what we need so that the car can turn through 90° in each direction

 

Car Chassis

Putting the physical aspects of the project together. See if we can put some microswitches or other sensors into the bumpers.

 

Other posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

One of the key features of the car is the lights. This will consist of headlights, brake lights and indicators. The thought is that the headlights can be controlled by the users and the indicators and brake lights will trigger automatically based on the motion of the car. Either way they will all ultimately be controlled by the Intel Edison and it's likely I'll use the Arduino breakout and Grove shield for its pluggable headers.

 

Headlights

The other year I had some LED downlights that failed on me. Curious to know what they had inside I cracked one open to see. After removing the glass and a load of potting compound I broke out a simple board with some LEDs on one side and a bridge rectifier and some resistors and capacitors on the other.

Power.jpgLED.jpg

After desoldering the components I tested the LED using an adjustable powersupply. The voltage was set to 2v and the current limit 20mA. I then increased the voltage until it started glowing. At 2.8v I had a workable brightness and at that voltage the LED was drawing between 3 and 5mA.

LedTesting.jpgSolderedUp.jpg

In the process of soldering these to some scrap PCBs, I discovered that the reason for 3 lots of connectors is that there are 3 individual LEDs in each package. I also discovered that some of the packages not all three of the LEDs were working. This might account for why the light failed in the first place as the original circuit seems to chain all the LEDs in series like Christmas tree lights. I'll likely need to re-measure the current now that I've worked out that there are potentially 3 times as many LEDs. If they take a lot of power then I'll use a PWM signal to dim them down a bit.

You might recognise the PCB if you are a Raspberry Pi Zero fan, it is from a batch of AverageManVsPi ProtoZeros where the silk screening failed quality control. I got them for the price of postage and they make great "tri-pad" boards for prototyping regardless of if you attach them to a Pi or not.

Once I've worked out the rest of the car chassis design I'll chop up the PCBs to mount them on the front of the car.

 

Brake Lights

In my box of electronic components I've a large number of 3mm red LEDs, I'm not actually sure where I got these but they have very short legs so I presume they came straight off a PCB. I've checked I've enough for a couple of sets of 6 LEDs to make for a nice bright brake light. The plan is to mount these on some stripboard or PCB similar to above.

 

Indicators

I also checked to see if I had any orange LEDs. I had 3 which was annoying as I'd need 4 for the indicators. However, I did have lots of white LEDs. So I designed an indicator block in OpenSCAD to be printed from some translucent orange filament that I bought the other year. I printed out a few tests and in the process noticed two things. Firstly that the light shone best where there was minimal infill I'd tried 40% and 8%. Also that my initial drill holes were so small that they just closed up. I realised that I could combine these two and have a zero infill to give a hollow box and then add some slits to force the slicer to add some extra supports for my screw holes. I also added a bubbly texture to the top to help diffuse the light.

BlockSlits.pngIndicatorBlock.png

https://github.com/Workshopshed/UpcyclingDesignChallenge/tree/master/3DModels

 

To test the light I inserted a white LED in the back and powered it from a couple of button cells. I'll print out the other three when I've a better idea as to how the bumper assembly will be put together.

IndicatorBlockLitUp.jpg

 

Other Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

For the software, I wanted to keep the UI loosely coupled from the control, I also have been wondering about blue tooth vs wifi. By using Node.js for the server side components that means the same language (javascript) can be used for all of the software which should make things simpler. Another advantage of Node is because it is multi-platform it can be written and tested without the need for the Edison. So I've been doing this on Windows so far.

 

Overview

My plan to achieve this is to use an MQTT broker to pass the commands. These will be simple text strings such as "L" for left, "R" for right, "F" for forward etc. Initially, the commands will be sent using WebSockets but it is also possible to send the messages over bluetooth via a client side API and an MQTT-SN to MQTT gateway such as Aquilla . I'm also wondering if I should change these commands to be JSON objects to simplify processing and also to allow the motion controller to queue up commands and hence make the system programmable.

 

Software.png

The broker will be run on the Edison so we don't need to have any external dependencies. The idea is to use Mosca to do this. It is possible to use Mosca directly in the code, but my plan is to have a separate Node application which I'm calling the "motion controller" this will take the messages and call the appropriate APIs to make the hardware move.

 

Code

 

In its the simplest form the motion controller subscribes to a topic and listens for messages.

 

#!/usr/bin/env node
// Listens for messages on a queue and moves car and driver
var mqtt = require('mqtt')
console.log('Connecting to Queue')
var client = mqtt.connect('ws://localhost:1884');

client.on('connect', function () {    
     client.subscribe('E14_UCDC/+/Commands')
})

client.on('message', function (topic, message) {
    console.log(message.toString());
    //Todo: Add movement code here.
})

 

The client side uses a different library as it runs in the browser. In it's simplest form it can send a message to the queue, on response to a button press, as follows:

 

  // Create a client instance
  var client = new Paho.MQTT.Client("ws://localhost:1884", "CarController");

  var message = new Paho.MQTT.Message("F");
  message.destinationName = "E14_UCDC/CarController/Commands";
  client.send(message);

 

For connecting to the hardware I'm looking at MRAA which can be accessed from Node and provides a simple way to access digital pins, I2C and PWM. This will be the first area to test once the Edison has arrived.

 

var mraa = require('mraa');
var pin13 = new mraa.Gpio(13);
pin13.dir(mraa.DIR_OUT);
pin13.write(1);

Reference

https://github.com/mcollina/mosca

https://eclipse.org/paho/clients/js/

https://github.com/Rodmg/aquila-mqtt-sn-gateway

https://github.com/intel-iot-devkit/mraa

Writing JavaScript for an Intel Edison

 

Other Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

The plan for the design challenge is to take some old bits that have been in my scrap drawer and make something interesting from them in the form of an interactive toy car and driver.

 

The Edison will provide the brain and communications which will allow the car to be controlled from a tablet or phone via MQTT. As the vehicle moves the headlights / indicators would activate and the driver would talk and move.

Overview.pngController.png

The vehicle is an old radio controlled car that has 2 motors and skid steers like a tank. I'm going to strip out the original radio from this and add an H-Bridge module to control the 2 motors. Also, a new battery box will be added to power the all the components. If there is time a new 3D printed body-shell will be added too. There are a number of sensors and actuators with the Grove kit so these can be used to add some extra functionality to the car.

2017-02-03 13.47.14.jpg

The driver is a first generation Furby from the 1990s. It's controlled by a single motor and some clever cams. This will need a bit of reverse engineering to find out how it works and what it is capable of. There's a speaker in the furby that can be hooked up to the Edison to play back messages and sounds from the SDCard.

2017-02-03 14.13.53.jpg2017-02-01 20.18.59.jpg

As mentioned in the proposal, I've a range of old electronics that have been salvaged over the years such as LEDs, micro switches, connectors, cables and displays. I will try to use these in preference to buying anything new. I'll try to remember where the particular parts came from but I have to confess I don't remember where I got some of them.