Skip navigation
1 2 Previous Next

Upcycle It

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

"What will you make?" asked the Intel Edison. The objective of the project was to upcycle an old RC car and a Furby to create an Interactive Race Car Driver using the Intel Edison and scrap or recycled components.

2017-02-01 20.18.59.jpgEdison.jpg

Car

One of the key features that attracted me to the car was that it had 4 screws located at the front and back. I knew those would make a good mounting point for a frame to which I could attach my components. The frame was printed using with recycled filament that used to be car dashboards. The screws came from old PCs and keyboards.

Before.jpg

The middle of the car housed the RC module and a container for the original battery pack. I checked if the H-Bridge of the RC module could be reused on a simulator and then in reality. It was designed never to stop so would not work for my project. So that was removed and swapped with an off the shelf module. The middle of the car was cut down and rewired using old PC cables.
Another feature that appealed to me was the 4 wheel drive skid steer setup of the motors. However only 3 of my 4 wheels were working so I had to repair the gearbox. Which I did with some gears from the spares box.
To my frame I attached lights and bumpers, along with a battery box. The lights were upcycled too, a broken downlight was disassembled to extract the LEDs for the headlights. 3mm RED LEDs for brake lights were salvaged from a keyboard, theses have yet to be incorporated into the car.

IMG_20170513_183058.jpgIMG_20170512_204700.jpgBatteryBox (1).jpg

I wanted the Edison to take pride of place so I styled that as the engine with the aid of some 3D printed parts, these were printed using recycled P.E.T. which used to be drink bottles.

IMG_20170508_210714.jpg
To simplify testing and wiring I used the grove shield and connectors. I put my own sockets on the breakout boards for the motor and lights. The boards I used for the lights were upcycled from some scrapped protoshields with poor quality silk screen that AverageManVsPi sent me last year.  The wiring for these boards was also upcycled where possible using old telephone cables. The bumper was also 3D printed and fitted with microswitches. The switches came from a broken shredder. The car is powered from a phone powerbank which clips onto the back of the car with 3D printed clips. Unfortunately my 3D print broke before I finished printing all the parts but temporary parts have been made from wood.

CarCircuit.png

All the 3D models can be found at: https://github.com/Workshopshed/UpcyclingDesignChallenge

 

Driver

The main donor component for the driver was a first generation Furby from the 1990s. Like the car this had it's H-Bridge swapped out with an off the shelf module. Also removed were the 2 chip on board modules that used to control the motion and sounds. These were replaced with wires that connected up to the Edison via some simple level shifters. The level shifters were made using more scrap protoshields and some transistors that most likely came from a radio.

InsideTheFurby.jpgIMG_20170521_194900.jpgEdisonBatteryAndAudio.jpg

 

The Furby's motion is driven from a series of cams. The position of those is sensed with a mechanical home switch and an optical sensor that pulses as the cam rotates. The LED for that sensor was replaced as it did not seem to be working. The output of the sensor went through some conditioning circuity to transistor to shift the signal level down to 1.8v for the Edison. The MCU was programmed to detect the pulses and count them.


To give the Furby a voice a USB audio card was plugged into the Edison. This was modified to have a micro USB connector. An amplifier module was added to drive the Furby's original speaker.

FurbyBlockDiagram.png

I got my daughter to record her best Furby impersonations and these were chopped into segments and copied to the Freddie board.

 

Upcycling summary table

ItemOrigin
Radio controlled CarSurplus store sometime in 1995.
FurbyProbably from a toyshop in late 1990s early 2000s.
Wire

Telephone Cable

PC Power Cable

PCBsScrapped Protoshield
Nuts, Bolts, ScrewsDecomissioned PCs and broken domestic appliances
MicroswitchesShredder
LEDs

Headlight LEDs from broken downlighter

Brakelights from computer keyboard

Level shifter transistors

Most likely from an old radio

Filament

ABS recycled from car dashboards

PET recycled from drink bottles

Wood

Sprue from Dollshouse

Offcuts from other projects

 

Software

Right from the start I decided to standardise on NodeJS for the code. I also wanted to be able to control the car from a phone or tablet. I wrote a simple web UI that connected back to the Edison using MQTT over Sockets. This was secured using certificates.

 

Software2.png

FurbySoftware.png

To read the signals from the optical sensor, the Furby uses the Edison's MCU and reports that back to the control software allowing the position of the action cam to be known. The Furby also hooks into MQTT too and responds to events from the car.

Car and Driver

 

{gallery} Closeups

CarMotorAndLightControl.jpg

Engine Bay: Wiring for lights, bumpers and motors, power converter to right

CarPower.jpg

Fuel Tank: The power for the car, the original on/off switch still disconnects the power

FurbyControlCentral.jpg

Under the seat: Level shifters, audio, power and Edison to control the Furby

CarEngineTheEdison.jpg

Car Engine: The Edison is what powers this beast of a car

CarAndDriver (1).jpg

Car and Driver: Completed car and driver

CarAndDriver (3).jpg

Car and Driver: Completed car and driver

CarAndDriver (2).jpg

Car and Driver: Completed car and driver

 

Car Demo

Car test using some simple nodeJS scripts.

Motion test

Light test

 

 

Driver Demo

Coming Soon

 

Thanks

Firstly to my family for putting up with 10 weeks of my madness and for their help, feedback and motivation.

Thanks to Intel for the Edisons, sponsoring the challenge and providing a great set of tools, documentation and O/S images.
Element14 for hosting the challenge.
Fellow challenges for their suggestions and ideas.
Previous Furby hackers: Kelly Heaton, Chris Brown and Northwestern University Mechatronics Design Laboratory
Harry Fairhead for his excellent notes on life at 1.8v.
Thomas Stratford and Alan Barnet for identifying my mystery transistors.
Brian and Enrico who offered to print parts when my printer broke.
And to the Element14 and Twitter communities for their encouragement.

After the various modifications, repairs and tests it was time to put the Furby back together. The speaker wires were soldered in place and all the cables hot glued to act as a basic strain relief. A hole was made through the battery box to route the wires through to the Edison (via the level shifters). The power cables were extended and a couple of damaged links on the board were replaced. Once that was done the case could be re-assembled.

FurbyGetsItsBodyBack20170528_220522.jpg

Power

As mentioned previously the Edison needs 7v to be able to power the board and USB correctly. To support this a boost regulator was added to the circuit based on the popular XL6009 chip. I initially planned to keep the 5v regulator from the origional battery box but that was not working when I tried it. Instead, I added a switch so that the battery can be switched between charging and powering. This can also be used as an off switch. I used the 100Ω high power resistor from the LED downlighter to load the board whilst I adjusted the output to 7v. I also checked that it stayed at 7v when the load was off.

FurbyPower.jpg FurbyBlockDiagram.png

Level Shifters

I tested the level shifters with a dual power supply and a multimeter. Three worked as expected but one did not. Rather than 7v / 0v, there was around 2v on the output. So I swapped out the FRB590 with a BC549 and it tested ok.

Level Shifter Testing TransistorLevelShifter.png

H-Bridge

The H-Bridge has been wired up and tested with the Furby's motor.

Update 4/6

I nearly forgot to include the H-Bridge but luckily there was a bit of space under the Edison.

HBridge.jpg

Edison

Thanks to gpolder and the pinout he found, soldering up the connections to the breakout board was straight forward.

EdisonPins.jpg

Update 4/6

 

Perhaps not as simple as I first thought as when I checked it again today one of the pins was in the wrong place, VBat vs Pin19. So I resoldered those.

 

My MCU code needed to be updated to reflect the new pins selected. I believe I have these correct but need to test them.

 

    gpio_setup(183, 0);  /* set GPIO 183 DIG9 as input*/

    gpio_register_interrupt(183, 1, IRQpulse);

    gpio_setup(49, 0);  /* set GPIO 49 DIG8 as input*/

    gpio_register_interrupt(49, 1, IRQreset);

 

Software

For the software side, the Furby needs to respond the events happening on the car. By subscribing to the same message queue as the car we can use pretty much the same code as for the car but just have different actions.

The previously developed MCU app communicates to the motor controller via the host control API and a bidirectional (or duplex) stream.

FurbySoftware.png

The duplex stream has "on" events for when data is recieved and a write method to send data.

var stream = require('stream');
var util = require('util');
var fileduplex = require('file-duplex');

var mcu = new fileduplex('/dev/ttymcu0');

mcu.on('data', function(data) {
    console.log('Data %s',data);
});

mcu.on('error', function(error) {  
    console.log('Error %s', error);
});

mcu.write("M"); //Request max value
mcu.write("C"); //Request counter value
//mcu.write("U"); //Count up
//mcu.write("D"); //Count down

 

Putting that together with the MRAA code from previous, we get the motor controller class for the Furby.

var mraa = require('mraa');

    var Motor = function (D1Pin, D2Pin, SpeedPin, HomePin, SensePin, mcuStream) {
    var self = this;

    self.MotorPin1 = new mraa.Gpio(D1Pin);
    self.MotorPin1.dir(mraa.DIR_OUT);
    self.MotorPin2 = new mraa.Gpio(D2Pin);
    self.MotorPin2.dir(mraa.DIR_OUT);
    self.MotorPinSpeed = new mraa.Pwm(SpeedPin);  //PWM available on default swizzler positions. (3,5,6,9)
    self.MotorPinSpeed.period_us(700);
    self.MotorPinSpeed.enable(true);
    self.mcu = mcuStream;
    self.positionDelta = 10;  //How many counter positions is close enough?
    self.counter = 0;
    self.max = 0;
    self.target = -1;    //What counter position to goto
    self.mcu.write("M"); //Ask the MCU to get the maximum value

    self.mcu.on('data', function(data) {
    switch (data.substring(0,1)) {
        case "C": {
            self.counter = data.substring(1);
            if (self.InPosition()) {
                console.log("Position found at %d", self.counter);
                self.Stop();
                self.target = -1;  
            }
            setTimeout(function() {self.mcu.write("C") },10);
            break;
        }
        case "M": {
            self.max = data.substring(1);
            break;
        }
        default:  
            console.log("Unexpected data recieved %s",data);
    }
    });

    self.mcu.on('error', function(error) {  
        console.log('Motor MCU error occurred %s', error);
    });

    self.Reset = function() {
        //Set the motor running for long enough to trigger a reset then stop
        var timeForOneRev = 1000;
        self.Forward();
        setTimeout(function() { self.Stop() },timeForOneRev);
        setTimeout(function() { self.mcu.write("C") },timeForOneRev);
    }

    self.Forward = function() {
        self.mcu.write("U");
        self.MotorPin1.write(1);
        self.MotorPin2.write(0);
    }

    self.Reverse = function() {
        self.mcu.write("D");
        self.MotorPin1.write(0);
        self.MotorPin2.write(1);
    }

    self.Stop = function() {
        self.target=-1;
        self.MotorPin1.write(0);
        self.MotorPin2.write(0);
    }

    self.Speed = function(percent) {
        self.MotorPinSpeed.write(percent);
    }

    self.Position = function() {
        return self.counter;
    }

    self.Max = function() {
        return self.max;
    }

    self.Distance = function(newPosition) {
        //What is the distance from the current position to the new position
        var p = self.Position();
        var m = self.Max();
        var D1 = newPosition - p;
        var D2 = (m - p) + newPosition;
        if (Math.abs(D1) < Math.abs(D2))
            return D1;
        else
            return D2;
    }

      self.Direction = function(newPosition) {
            return Math.sign(self.Distance(newPosition))
      }

      self.InPosition = function() {
          if (self.target == -1) return false; //Not going to a position
          return ((self.Distance() * self.Direction()) < self.positionDelta);
      }

      self.Goto = function(newPosition) {
            self.target = newPosition;
            if (self.InPosition()) {
                self.target=-1;
                return;
            }
            if (self.Direction(newPosition) > 0) {
                self.Forward();
            }
            else {
                self.Reverse();
            }
      }
};

    module.exports = Motor;

 

There's still a bit to be done with the software but I hope to have enough for a demo this weekend.

 

Reference

XL6009 DC-DC Converter Datasheet

How to create duplex streams with Node.js - a Nodejs programming tutorial for web developers | CodeWinds

https://nodejs.org/api/stream.html

https://www.npmjs.com/package/file-duplex

 

Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

So this was supposed to be a joyful post about how I'd printed the redesigned backlight bracket and a base for the Furby to hold the Edison and other parts.

LightBar.png FurbyBase.png

However, before printing, I got a warning message on the printer and the printer refused to print. When I took the head off I realised why as there was a load of blue PET behind the print head.

NozzleError.pngPrintHead.jpg

Despite various attempts to remove the plastic from using the purge cycle to heat the head and tweezers to using a soldering iron to carve through the plastic, I could not remove it. I fact I think I've made the problem worse and narrowly avoided setting the smoke alarm off.

 

I don't think there will be any more prints this week and I'll likely need to save up for a new head.

 

Updated - Wood and glue save the day

Dolls house offcuts

When I assembled a dolls house kit the other year, I kept all of the 3mm ply that formed the frame where the parts were pushed out. None of the parts were particularly large but I thought they might come in handy for models and the like.

 

So I cut some squares and some blocks and glued up some piles to support the Edison, it's not elegant and is taller than I wanted but will do the job till I can print a replacement for the platform I was going to make.

Platform (1).jpgPlatform (3).jpg

Reference

RBX01-S2 - Single Material Dual Nozzle Head- Version 2 - Replacement and spare parts - Robox

Woodcraft Dolls House Kit

 

Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

As much as I was enjoying messing about with the mechanical part of the Furby there was still a big unknown for me that I wanted resolved. That was how to get the sound to make the Furby speak. I had considered an I2S audio module as that does seem the more elegant option. However, as I'd already decided to control my Furby using the breakout board that meant that I was working with 1.8v I/O so I2C could be problematic.

 

Instead, I went for the USB option with a cheap USB module from Ebay that mentioned it supported Linux. I'd bought this right at the beginning of the challenge as I'd heard that Ben Heck has gone for USB Audio in his last project. Apart from plugging it into a windows machine to make sure it actually worked I'd not done anything with it..

s-l500.jpg

I spotted a few other challengers have already used USB sound so I had a quick read of their articles.

[Upcycle it Design Challenge] Embedded Web SDR client on Analog Radio Receiver #8: Problem with Audio.

Upcycle It - Funeka - The Skull #5 : Ohh, it's music to my ears

Blog Entry #1: Recording and Calibrating the Tockman

 

Looks like aplay is a nice simple way to play the audio file and that can be called from nodejs either as a child process using execFile or via a npm package. These are both asynchronous so I can get on with other things such as making the mouth move whilst the sound is playing.

 

Setup

I booted up the Edison Arduino with the audio card wired in and ran :

lsusb

 

To see all the devices, instead I got an error.

unable to initialize libusb: -99

 

To check that the USB was present I ran

lspci | grep USB

 

And that returned

00:11.0 USB controller: Intel Corporation Device 119e (rev 01)

 

Googling the above error -99 I found that it was simply that I needed to swap SW1 from Device to Host.

 

I repeated the command (and got a strange red light on the Audio card) and the following was returned:

root@Eddie:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0d8c:013c C-Media Electronics, Inc. CM108 Audio Controller
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

Next following the "Rock out with the Edison" article I checked that there was a PCM audio device available.

root@Eddie:~# cat /proc/asound/pcm
00-00: Loopback PCM : Loopback PCM : playback 8 : capture 8
00-01: Loopback PCM : Loopback PCM : playback 8 : capture 8
01-00: 14 :  : playback 1 : capture 1
01-01: ((null)) :  : playback 1 : capture 1
01-02: ((null)) :  : playback 1 : capture 1
02-00: USB Audio : USB Audio : playback 1 : capture 1

 

Next up was checking the playback and audio devices with PulseAudio sound server control

root@Eddie:~# pactl list | grep Name | grep usb
        Name: alsa_output.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00-Device.analog-stereo
        Name: alsa_output.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00-Device.analog-stereo.monitor
        Name: alsa_input.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00-Device.analog-mono
        Name: alsa_card.usb-C-Media_Electronics_Inc._USB_PnP_Sound_Device-00-Device

 

Test

I wanted to know if the sound would be loud enough so I plugged in some headphones. I was looking for a test sound to try so I did some googling and found these sounds Electronic Furby: Furby Sounds but I decided to go with http://sounds.stoutman.com/sounds/better.wav  instead.

 

Aplay showed my card listed as card 2: Device

root@Eddie:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: dummyaudio [dummy-audio], device 0: 14 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

 

So I played the file using "Device" as that is the name of the USB audio.

 

aplay -D default:Device better.wav

 

It's possible to configure the ALSA subsystem so that the USB device is the default so I may do that in the future.

 

Turn it up to 11

The volume from the headphones was not very loud so amplification was necessary. Interestingly, the Furby does not have an audio amplifier although that may be tucked away in the COB#2. So I used a new PAM8302A 2.5W amplifier module.

Amp.png

I wired the amplifier supply to the power lines on the USB, IN- to GND, IN+ to one of the audio channels and /SD to +5v. And tested.

Edison Arduino Breakout with Audio

 

USB On the Go

The Edison mini has micro USB sockets and my sound card had a full sized USB. I could have included an adapter but instead I decided to put on a micro-USB connector with the suitable OTG wiring i.e. pins 4 and 5 shorted, so that it would correctly be detected by the Edison.

 

Here's the connections seen from the plug end.

USBOTG.png

It was at this point I realised I still had an issue powering the Mini-Breakout board. Because of the extra regulator on the J21 route it won't run from the 5v I was producing from my battery box. It would run fine from the USB (at 5v) but I now needed that for the sound card.

The Grove kit came to my rescue in that it had a PP3 to Jack connector. I cropped that off and connected on a 2 pin socket.

I plugged it all together and my audio did not work. I had a little adapter that turns big USB into mini so I used that with a memory stick to check that the port was working. It was, so I returned my audio card to the bench and resoldered the connections. I hooked it back up and this time it was properly detected. So I tested it one last time with the audio file, "I'm feeling better now, I really am".

EdisonAndBattery.jpgEdisonBatteryAndAudio.jpg

https://youtu.be/i-d8-FxrRbs

 

Reference

Intel® Edison Audio Setup Guide

Advanced Linux Sound Architecture

Rock out with Edison

2.5W Class D Audio Amplifier - PAM8302

Max98357 I2S Class D Mono Amp

Maxim - Understanding USB On the Go

Understanding execfile spawn exec and fork in node

How-to-make-your-own-usb-otg-cable-for-an-android-smartphone

 

Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

In the previous post, I looked at Hooking up the Furby to the Edison. Now to put that together with some software so we can control what the Furby does.

 

Motor

Driving the motor from the H-Bridge board is pretty much the same as per  [Upcycle It] Interactive Race Car Driver - Powering Motors although there are the extra transistor level shifters to factor in. This means all of the signals are inverted.

 

TransistorLevelShifter.pngIMG_20170521_194900.jpg

MCU

As I discovered that the rate of pulses from the optical sensor is quite high, I decided that the MCU capability of the Edison would be ideal to monitor the inputs. Then a Node program can be used to get the current value of the counter from the MCU. So that the MCU knows which direction that the Furby's cam wheel is rotating a simple message can be sent over the serial communications channel.

MCU

Installing the MCU SDK

Installation of the SDK is straightforward, it's an Eclipse-based application so to get that to work on Windows there are quite a few extra components to install such as JRE and Cygwin.

 

I did have a few issues creating projects and this seemed partly due to my Workspace folder and partly because of my installation.

 

Ensure you:

  • Keep paths short
  • Keep paths without spaces in them
  • Install all of the components
  • Set the Environment variable

 

Installing the MCU SDK

 

Target IP

Unlike a lot of embedded SDKs the MCU SDK uploads the code over the network. So before you can upload your project you need to set the TARGET_IP. So I set that to the name of the board and it worked just fine.

LocalIP.png

For .local addresses to work on Windows, you might need to install a service such as Bonjour

 

https://learn.adafruit.com/bonjour-zeroconf-networking-for-windows-and-linux/overview

Sample Scripts

There are some tools that can help to configure the ports, it's worth downloading these as unlike things like MRAA, the MCU code "gpio_setup" does not actually configure the hardware to be an input or output.

 

Sample scripts for the MCU SDK

 

I installed the init_DIG script as follows:

 

mkdir tools
cd tools
wget http://downloadmirror.intel.com/24910/eng/init_DIG.sh
chmod +x init_DIG.sh
cd ..

 

Then configured a couple of the pins with:

 

./tools/init_DIG.sh -o 7 -d input
./tools/init_DIG.sh -o 8 -d input

 

This article Using an mcu on the intel edison board with the ultrasonic range sensor confirms that you need to do this each time the Edison boots. I'm also wondering if I can use MRAA to configure the ports in the control code for the Furby.

 

Testing

For initial testing, I used the grove shield, a switch for counting and capacitive sensor for reset.

 

The MCU application detects the signals with the aid of two interrupt handlers.

gpio_register_interrupt

Register an interrupt handler for one GPIO port.

int gpio_register_interrupt(int gpio, int mode, irq_handler_t isr);

...where:

  • gpio: GPIO port number
  • mode: 0 = falling edge interrupt, 1 = rising edge interrupt
  • isr: interrupt handler function
  • Return value: 0 if successful

The status is reported via the debug port and the current count can be received via the host to mcu serial port /dev/ttymcu0. I limited the counts to 50 for this initial testing to check it wrapped around correctly.

 

MCU Test code

#include "mcu_api.h"
#include "mcu_errno.h"
volatile int counter;
volatile int direction;
int maxPulses;
 int IRQpulse(int req)
 {
   counter += direction;
   if (counter < 0) {
    counter = maxPulses;
   }
   if (counter > maxPulses) {
    counter = 0;
   }
   debug_print(DBG_INFO, "Counter: %d\n",counter);
   return IRQ_HANDLED;
 }
 int IRQreset(int req)
 {
   counter = 0;
   debug_print(DBG_INFO, "Reset.\n");
   return IRQ_HANDLED;
 }
 void mcu_main()
 {
 char buf[64];
 char response[20];
    int retCode;
    int len;
    debug_print(DBG_INFO, "mcu app starting...\n");
    direction = 1;
    maxPulses = 50;    //Max pulses per revolution (need to find this experimentally)
    gpio_setup(48, 0);  /* set GPIO 48 DIG7 as input*/
    gpio_register_interrupt(48, 1, IRQpulse);
    gpio_setup(49, 0);  /* set GPIO 49 DIG8 as input*/
    gpio_register_interrupt(49, 1, IRQreset);
    while (1)
    {
     //Wait for command from host
     do {
      retCode = host_receive((unsigned char *)buf, 64);
         mcu_sleep(10);
     } while (retCode <= 0);
     switch(buf[0]) {
        case 'C'  :
         debug_print(DBG_INFO, "Counter: %d\n", counter);
         debug_print(DBG_INFO, "Direction: %d\n", direction);
         len = mcu_snprintf(response, 20, "C%d\n", counter);
         host_send((unsigned char*)response, len);
            break;
        case 'U'  :
        debug_print(DBG_INFO, "Up\n");
        direction = 1;
           break;
        case 'D'  :
        debug_print(DBG_INFO, "Down\n");
        direction = -1;
           break;
     }
    }
 }

 

I could not get Eclipse to display the debug log but from a console I could display it with:

 

cat /dev/ttymcu1 &

 

To interact with the MCU I used the 3 letters, C to display counter, D to count down and U to count up.

 

echo C > /dev/ttymcu0
echo D > /dev/ttymcu0
echo U > /dev/ttymcu0

 

CounterTest.png

The reset and pulse counters proved to work correctly. There are reports of the MCU not being able to cope with very high pulse rates. If this is the case I'll drop the debug statements and change the speed of the motor until it works reliably.

 

Monitoring the position

Once I was happy the MCU was working as expected I hooked the inputs upto the Furby. So that I could move both forward and backwards I needed to know the maximum number of pulses. To find this, I set the max in code to a large number and planned span the motor by hand.

 

Initially when I set this up the reset line was going wild. I used a resistor to pull that high and confirmed it worked by manually closing the contacts.

I manually span the slotted disk and after a short delay I got a reading of 209 pulses. Note to self, that needs to go to 1.8v when it's wired up to the mini-breakout.

 

I repeated this experiment with the motor driven from a battery and there was a debounce problem where I was getting multiple resets. Given that it was a mechanical spring contact this is not surprising. I added a simple delay into the reset interrupt handler and that improved the problem but did not completely eliminate the problem with a "bounce" appearing 7 or so pulses later. I'll likely use a mechanism where the reset initialtes a countdown and can't be retriggered until 10 or more pulses have been detected.

HomeSwitch.jpg

These experiments did provide repeated results of 208 pulses per revolution. I added that into the code and also added a call via the host API to return this max value. This experiment also demonstrated that the MCU was happily counting pulses and not obviously skipping.

 

Latest MCU code

#include "mcu_api.h"
#include "mcu_errno.h"
volatile int counter;
volatile int direction;
int maxPulses;
 int IRQpulse(int req)
 {
   counter += direction;
   if (counter < 0) {
    counter = maxPulses;
   }
   if (counter > maxPulses) {
    counter = 0;
   }
   debug_print(DBG_INFO, "Counter: %d\n",counter);
   return IRQ_HANDLED;
 }
 int IRQreset(int req)
 {
   counter = 0;
   mcu_sleep(20);  //Debounce
   debug_print(DBG_INFO, "Reset.\n");
   return IRQ_HANDLED;
 }
 void mcu_main()
 {
 char buf[64];
 char response[20];
    int retCode;
    int len;
    debug_print(DBG_INFO, "mcu app starting...\n");
    direction = 1;
    maxPulses = 208;    //Max pulses per revolution, was determined experimentally
    gpio_setup(48, 0);  /* set GPIO 48 DIG7 as input*/
    gpio_register_interrupt(48, 1, IRQpulse);
    gpio_setup(49, 0);  /* set GPIO 49 DIG8 as input*/
    gpio_register_interrupt(49, 1, IRQreset);
    while (1)
    {
     //Wait for command from host
     do {
      retCode = host_receive((unsigned char *)buf, 64);
         mcu_sleep(10);
     } while (retCode <= 0);
     switch(buf[0]) {
        case 'C'  :
         debug_print(DBG_INFO, "Counter: %d\n", counter);
         debug_print(DBG_INFO, "Direction: %d\n", direction);
         len = mcu_snprintf(response, 20, "C%d\n", counter);
         host_send((unsigned char*)response, len);
            break;
        case 'M'  :
         debug_print(DBG_INFO, "Max: %d\n", maxPulses);
         len = mcu_snprintf(response, 20, "M%d\n", maxPulses);
         host_send((unsigned char*)response, len);
            break;
        case 'U'  :
        debug_print(DBG_INFO, "Up\n");
        direction = 1;
           break;
        case 'D'  :
        debug_print(DBG_INFO, "Down\n");
        direction = -1;
           break;
     }
    }
 }

 

What next?

Test the H-Bridge with the mini-breakout and level shifters

Test the Sensors with the mini-breakout and level shifters

Write some high-level control code that communicates with the MCU and uses the counts from the Northwestern team to drive specific motions e.g. talking, ears waggling.

 

Reference

Installing the MCU SDK

Registering_an_interrupt_handler_to_a_GPIO_port

MCU API

Using an mcu on the intel edison board with the ultrasonic range sensor

Sample scripts for the MCU SDK

MCU interrupt performance

 

Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

As mentioned in the Furby Hacking post the Furby is powered with a motor and cam system with different actions at different points in the rotation. The position of the cams is determined by a simple spring switch that is closed once per revolution. Then the relative position is determined using an optical sensor consisting of an LED, phototransistor and some buffers. So to control all this from the Edison I need to provide power to the 74HC14 chip, turn on the LED, monitor the gear position sensor and drive the motor.

 

Furby Control Schematic

 

Board modifications

As mentioned I've already removed the Furby's brain and voice box.  I did think about if I could use all or part of the H-Bridge as a level shifter to pass the signals to the TB6612FNG board. However due to the tiny surface mounted resistors not really having appropriate values I decided instead to remove all of those transistors to avoid any unintended behaviour such as shorting the power rails. I also removed the wires for the back sensor as those were directly attached to the board rather than being jumpered. That allowed me to work on the board completely separate from the mechanics.

Stripped down board

 

Power

The Furby has a surprisingly sophisticated power setup. It has raw 6v from the batteries, 5.13v used by the main processor, 4.86v used by the EEPROM and a switched 6v used by the audio and IR sensors.

Power Supplies

One thing that is missing from the schematic is what powers the 74HC14 which is used for the driving the LED and processing the opto-sensor signal. I checked and it was connect to the 6v line.

 

The Edison has an even more complex setup. The key thing here is that the 3.3v line can only source 100mA so I'd have to be very careful if I wanted to use that to drive any part of the Furby.

EdisonPower.png

USB Breakout Notes

 

So my chosen approach is to power the Furby from its own battery connectors. The voltages will be slightly lower than design as I'm using a 5v supply rather than 6v but are still well within the range of the 74HC14 and sensor components.

 

The Edison will be powered from the J21 connector so that I can connect an audio card to the USB.

 

I've broken down a second powerbank into it's constituent components. It's interesting to see that there is just a single MP3401A chip and a few discrete components.

PowerbankIMG_20170519_220814.jpg

Home Switch

The home switch is the simplest part of the circuit. I confirmed that one side was grounded and soldered a wire onto the COB header so that I could test it. To test, I added an LED and resistor connected to the positive supply.

Switch

LED

The LED for the opto-sensor is linked to the inverting buffer. I checked the schematic and the LED was connected to +Vcc but as suspected the orientation was reversed. I tried to get it to light and there was nothing so I pondered if it was an IR LED. So I soldered a second LED in parallel. This also produced no result (retrospectively this could be due to different junction voltages) so I unsoldered the original LED and replaced with a white LED. My theory was that the sensor might be only sensitive to a specific wavelength so the white would cover the most options, it also allowed be to visually check that it was on.

 

Phototransistor

The output of the phototransistor is fed into a Schmitt Trigger inverting buffer in the form of a 74HC14. The Schmitt trigger cleans up the signal to a nice square wave so it will be easy to detect a rising edge with the Edison. As suspected the schematic for the transistor was reversed.

To test the photo-transistor I wired an LED and resistor in series. The Furby was re-assembled and the slotted disk was rotated. The LED turned on and off as desired. When this is run from the motor it flashes faster than the eye can see so I'll have to ensure that the signals are processed fast enough.

 

 

Motor

As mentioned the H-Bridge transistors were removed. This provided some spare sockets to attach a connector. A right angled connector was used as there was not a lot of vertical space. I plan to us the PWM option on the motor driver board so that the motor runs more slowly. The process for that is the same as [Upcycle It] Interactive Race Car Driver - Powering Motors

 

Eyelid Fix

Whilst testing the motor, I realised the eyelids on this Furby were closing but not re-opening, I discovered that the rubber coated cam was slipping on the back of the eyelids so I used a knife to score the plastic. That now works as correctly.

 

FurbyEyes

Level Shifters

I soldered up my FRB590 transistors as per Harry Fairhead's suggestion in Exploring Edison - Life At 1.8V again using one of the scrapped Protozero boards.

LevelShifters.png

IMG_20170521_194900.jpg

Next Up

The driver is a complex part of the project so there's going to be another week of work on this. The main item is connecting up the sound to the Furby's speaker.

 

Reference

Hardware Guide for the Intel® Edison Breakout Board

Hardware Guide for the Intel® Edison Compute Module

Furby Schematic

Schmitt trigger design

Exploring Edison - Life At 1.8V (Harry Fairhead)

 

Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

For my indicators, I wanted a simple function that would blink them 5 times then stop. I found a suitable piece of code on Stack Overflow which did the same thing for some flashing text and ported it across to node. However, I did not have the Edison to hand so pondered how I would test it. A quick google found mraaStub  a mock version of mraa that you can use on platforms that don't have mraa hardware. I installed this and discovered that it needs a logging package called "winston" which I also installed. I also had to tweak the mraaStub library so that it would log by default. My version can be found at https://github.com/Workshopshed/UpcyclingDesignChallenge/tree/master/mraaStub

 

//Simple function to test the indicator

var platform = require('os').platform();
var m;

if (platform === 'win32') {
    m = require('mraaStub'); //also needs winston
} else {
    m = require('mraa');
}

var myLed = new m.Gpio(13); //LED hooked up to digital pin 13 (or built in pin on Galileo Gen1 & Gen2)
myLed.dir(m.DIR_OUT); //set the gpio direction to output

function indicate() {
    var count = 1;
    var ledState = true;
    var intervalId = setInterval(function() {
        myLed.write(ledState?1:0);
        ledState = !ledState;
                if (count++ >= 10) {
                clearInterval(intervalId);
            }
    }, 500);
};

indicate();

 

Here's how it looks in Visual Studio Code when it is running.

 

Reference

javascript - Making text blink a certain number of times? - Stack Overflow

https://www.npmjs.com/package/winston

https://www.npmjs.com/package/mraaStub

https://github.com/Workshopshed/UpcyclingDesignChallenge/blob/master/Tests/test6.js

https://github.com/Workshopshed/UpcyclingDesignChallenge/tree/master/mraaStub

 

Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

3d Printing

The 3D printing and car modification has run into a second week. Although each of the components does not take a long time to print there are a lot of them so it does add up. I've been printing with the recycled filament which has printed ok with the exception that the PET does not span well. This means I need to design my parts accordingly.

 

Lights

A curved section was printed to support the lighting components. Although curved this was printed curved side down with supports so that I did not need to create a complex scaffold to do the cutouts for the lights. This printed without issue and I cleaned off the supports.

Light Block

A lamp housing was created for the headlights. Which was a simple box with a concentric rings on the front. This was put together with the previously printed indicators and the above plate.

IMG_20170512_204617.jpg

These were tested by simply hooking up the supply.

 

 

A block was added to the bottom so that this section could be bolted to the bumpers.

 

Bumpers

The bumpers went through a few changes since last week. To produce the best flex in the bumper the pivot point was moved right to the middle and the design was adjusted accordingly. Some mounting holes were added so that this could be bolted to the bumpers.

IMG_20170513_183145.jpg

Chassis

The chassis has been slimmed down as previously mentioned and the mounting points for the bumpers were spread apart so that they cleared the existing frame. The chassis was printed with the black ABS from Refil (ex car dashboards) and it printed without problem. I did drill out the mounting holes to 3.5mm as I suspected that my printed sizes were a little small.

 

Wiring

The front lights wiring has been finished off this week with a NPN transistor being added so that the headlight LEDs can be driven. The grove connectors have also been wired up. I realised that I could also put the bumper switches through the same board so an additional grove connector has been added and wired up to the resistor network described in [Upcycle It] Interactive Race Car Driver - Bumper switches and wiring loom I just need some spade connectors to finish the complete assembly.
IMG_20170514_110912.jpg

Putting it together

When I came to assemble the printed parts there were a few issues. The first was that the new lights and bumper clashed with the existing frame. A hacksaw quickly solved that problem and the frame was shortened. I also dug into my bag of reclaimed screws and bolts and found 4 that would fit the chassis nicely. I also found that the lights and bumpers were higher than I wanted so I chopped up the back bumper and glued it to the top of the front lights to allow those to hang below. This meant that the front assembly hangs a long way from it's supports. So I'll need to add an additional brace at the bottom, there's a handy screw point that I'll likely attach that to. With a three point mounting the lights and bumper are solid. I'll likely incorporate these changes into the models so that the back bumper/lights are simpler to assemble.

 

As you can see the battery pack and Edison balance each other out and since I've taken these photos I've moved the batteries further back to give my driver more space.

IMG_20170513_225424.jpgIMG_20170513_225515.jpg

Freddie

I've been preparing the driver which my daughter has nicknamed Freddie. The second Edison has been flashed, connected up to the network and configured for SSH.

 

As mentioned in the previous discussion the Edison breakout board runs at 1.8v volts. The 74HC14 Schmitt triggers that are used on the driving the LED and monitoring of the position sensor can run down to 2v so to interface these to the Furby something is needed. Referring to Harry Fairhead's book on the Edison Exploring Edison - Life At 1.8V the approach of using a simple transistor to boost or lower the voltage seems the best option.

 

MotorSensors.png

Transistors

In my collection of salvaged parts I had 5 identical transistors. The "FRB" code seemed the ideal choice to put in the Furby but I could not find out what transistors they were. Luckily a friend from twitter @MrTomsWorld has a gadget (Peak Atlas DCA55) to test them so I posted him one and he identified it as NPN and sent me the pin details. Following this, I was showing the results to my radio ham friend Alan. From the design he commented it was likely to be a silicon transistor and commented that if you prefix with "2SD" then you should find the transistor that way. A google search found me the datasheet and spec.

Transistors.jpgTransistor.jpg

2SD590

Material of transistor: Si

Polarity: NPN

Maximum collector power dissipation (Pc), W: 1

Maximum collector-base voltage |Ucb|, V: 100

Maximum collector-emitter voltage |Uce|, V: 90

Maximum emitter-base voltage |Ueb|, V: 6

Maximum collector current |Ic max|, A: 2

Maksimalna temperatura (Tj), °C: 200

Transition frequency (ft), MHz:

Collector capacitance (Cc), pF:

Forward current transfer ratio (hFE), min: 100

Noise Figure, dB: -

Package of 2SD590 transistor: TO39

 

Reference

Exploring Edison - Life At 1.8V

74HC1474HC14

2SD590 transistor

 

Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

The observant amongst you will have spotted that there was an item in the  [Upcycle It] Interactive Race Car Driver - 3D Printed Parts article that did not relate to any of the things I was printing. That was because I did not know if it was going to print ok or not. The part is some "exhaust pipes" to add to the Edison to turn my "engine" into a hotrod.

Edison EngineIMG_20170508_210714.jpg

Because I was concerned about the exhausts wobbling about when printing I added some 1mm horizontal supports to the model which were then cut off using a knife following the print. The print went well until layer 165 of 168 at which point it came detached from the print bed. As I was printing at 100% fill this did not actually matter and I've gone with fractionally shorter pipes by 0.9mm. If I was going to print it again I'd likely use a brim around the base to give it a bit more grip.

Model

You can find all the models at https://github.com/Workshopshed/UpcyclingDesignChallenge/tree/master/3DModels

 

I don't think my modification will make any difference to the Edison's performance but I do think it looks cool. Hopefully, I'll have time to give it a coat of silver paint so it looks more like exhaust pipes.

 

Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

Recycled filament

I had intended to use some recycled filament from a Kickstarter. However, as with many Kickstarters it has been delayed. So Instead I ordered some filament from a dutch firm, Refil. They get their filament from 2 different places. The first is from bottles, these are a material called "PET" and comes in a transparent but coloured materials. The second is ideal for my chassis, it is black (dark grey) ABS which comes from old car dashboards, it seems fitting that an old car should become part of a new car.

 

Software

I've used different CAD packages over the years but recently I've been doing a lot with OpenSCAD. This is different from a lot of CAD packages in that the only way you can create objects is via scripting.

 

Here's a simple example of a cylinder joined to a circle which has been extruded around a 70degree corner.

 

module Exhaust() {
    union()
    {
    translate([1.81,4.66, 0])
        rotate([-20,-90,0])
            cylinder(r1=1.5,r2=2.5,h=30, $fn=100);

    rotate_extrude(convexity = 10, angle=70, $fn=100)
        translate([5, 0, 0])
            circle(r = 1.5, $fn = 100);
    }
}

Exhaust

I find it is good for 3D printing as you can tune the parameters as you build different models. As it's a coding language naturally parts that are repeated in arrays or circles are easy to reproduce. It's less good at producing organic items such as trees although you could use "fractal" algorithms for that kind of thing.

I have been working around a bug where the "difference" function causes things to disappear on one of my Win10 machines. Something to do with Java and incompatible video drivers apparently.

Parts

One technique I used on several of the parts was to print out a couple of layers and then cancel the print to give a floppy template. This allowed me to cross check the dimensions and ensure things would fit together.

 

Chassis

The chassis serves several purposes: it's there to strengthen the middle section that was weakened by the cutting down; it provides mounting for the battery and Edison, and it provides an attachment point for the bumpers. This has gone through many iterations, the initial models were massively over engineered with 10mm thick struts and would have taken many many hours to print. So it's been slimmed down and simplified. The other key design feature was making it short enough to fit on my 210mm printer bed. After watching a video by Vicki Somma, I realised that the buffers that held the bumpers in place would be better as octagons so that when I print the sockets on the mating parts they won't have a big span to cross. The design changes cut the predicted print time from 4hrs to 2hrs 20minutes and also the amount of filament used is reduced.

Chassis

Bumpers

I had initially thought about attaching the bumpers with rods and springs but I realised that I can use the springy properties of the PET plastic and just attach them directly to lugs on the chassis. Here's my sketch and models of how these might be built.

Buffers.jpgBumper1.png Bumper3.png

Edison Support

The Edison needs attaching to the car so I wanted something that looked like it was part of a car. I created a part with a fuel tank, exhaust, battery and a belt driven pulley. To reduce the material used in the print (and hence reduce print time) I added some hollowing out below the parts. I printed the part in draft-mode using some green ABS that I had available. I've a selection of self-tapping screws harvested from various old computer parts over the years so I'll use those to attach the Edison to the support.

EdisonSupport.png IMG_20170501_200711.jpg IMG_20170501_211603.jpg

Battery Clip

My initial model for the battery clip was all in one part. I realised that this would mean that the clips would be quite tall. This has two issues, firstly a long print time and secondly, it was a risky print as the vertical parts might move during the print and cause failures. So I redesigned it in 3 parts connected with a dovetail joint. This meant that the clip parts could be printed on their sides and hence would be a lot shorter and more stable. Initially, the material seemed to bond well to the bed but there were a couple of failures where it broke off. So I fined tuned the temperature settings and sizes and re-printed, I also added a brim although I'm not sure that was strictly necessary.

BatteryClip.pngBatteryBox (1).jpgBatteryBox (3).jpg

BatteryBox (2).jpg

Drivers Seat

The seat is there to hold the Furby driver in place, it will also hold the motor driver board in place. Key design features will be that it will straddle the chassis and need space for routing the cables. As the photo below shows the driver board will likely be mounted vertically on the back of the chair.

IMG_20170507_175347.jpg

Car Body

I've not started designing the car body yet but the plan is to use a green recycled PET for that. Hopefully, it will be possible to print a thin walled model so the electronics can be seen through the plastic.

 

Reference

OpenSCAD - The Programmers Solid 3D CAD Modeller

Refil - The makers of recycled filament

Embedding Nuts into 3D Printed Tap Handles

 

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

[Upcycle It] Interactive Race Car Driver - Powering Motors

[Upcycle It] Interactive Race Car Driver - Bumper switches and wiring loom

[Upcycle It] Interactive Race Car Driver - Securing MQTT

In my previous look at the software I looked at connecting up a web client to an MQTT server.

 

Picking a broker

 

Thanks to Jason I realised that the Mosquitto Broker that's provided is an old version (1.3.4) that does not support WebSockets. I tried to update using "opkg install mosquitto" but that told me I was on the latest. So instead I removed it and it's the packages that depended on it.

 

# opkg remove mosquitto --force-removal-of-dependent-packages

Removing package iotkit-comm-c-dev from root...
Removing package iotkit-comm-c from root...
Removing package iotkit-comm-js from root...
Removing package mosquitto-dev from root...
Removing package mosquitto from root...
rm '/etc/systemd/system/multi-user.target.wants/mosquitto.service'

 

I then installed the Mosca broker using npm, that had worked well for me on Windows for testing so I might as well use that for the car.

 

npm install mosca

 

There were some errors about not being able to compile Kerberos due to missing missing gssapi/gssapi.h. I realised that kerberos was just for cross domain authentication so would not be an issue for my configuration.

So that we can easily start mosca, a link can be added as follows:

 

ln ./node_modules/mosca/bin/mosca /usr/bin/mosca

 

I'll also add in a boot up option so that it starts automatically.

 

I also installed the npm modules mqtt and queue.

 

Creating a certificate

I'm developing on windows so I used a simple powershell cmdlett to create the certificate in my local store.

 

New-SelfSignedCertificate -DnsName "workshopshed.com", "www.workshopshed.com" -KeyFriendlyName "Workshopshed"

 

I then extracted the certificate and private key as a .pfx file with a simple password. This needs the format converting before you can use it with an MQTT broker so I did that with ssl-converter and ended up with a .PEM file.

Note, that you can also do these steps using the OpenSSL toolkit or you can create a real certificate with something like LetsEncrypt

Configuring the MQTT Broker

To run Mosca with a certificate you can add a couple of command line parameters.

 

./mosca -v --https-port 1884 --only-http --cert TestCertificate.pem --key TestCertificate.pem

 

Configuring the client

The client uses the Web Browser to determine the certificates so we can add the test certificate viewing the certificate manager, adding an exception by browsing to the location of the mqbroker and getting the certificate (Firefox). It will likely report that this is the wrong site and is not trusted. You can view the certificate to confirm that it's the one you added to the broker.

Exception.png ExceptionManager.png

The code also needs to change slightly to tell Paho to use TLS encryption.

 

var client = new Paho.MQTT.Client("localhost",1884, "MyClientID");
client.connect({useSSL:true,onSuccess:onConnect, onFailure:onConnectFail});}

 

Configuring the listener

On the server side, our command listener also needs to be configured to use TLS. This is done using some options when we connect. I've chosen to ignore the unsigned certificate but it is also possible to set options to load up the certificates so that we can validate them.

 

var options = {
  port:1884,
  rejectUnauthorized: false,
  protocol: 'wss'
}

var client = mqtt.connect('mqtts://localhost', options);

 

Change to use JSON

I've also changed my code to use JSON rather than simple messages.

 

On the client I create my messages as follows:

 

       var message = new Paho.MQTT.Message(JSON.stringify({ action: "DOWN", timeOut: 1000}));
       message.destinationName = 'E14_UCDC/MyClientID/Commands';
       client.send(message);

 

And on the server, the listener converts this back and passed them over to the controller for processing.

 

client.on('message', function (topic, message) {
    var command = JSON.parse(message.toString());
    controller.addMovement(command);
    console.log(message.toString());
})

 

This decouples the listener from the commands so that I can add new commands into the controller in future without worrying about the transport.

 

My controller queues up the messages and can play them back when it receives a "Run" command.

 

var queue = require('queue');

var controller = function() {

  this.q = queue();
  this.q.concurrency = 1;

  //Expect a movement object formed of a command and timer to be passed { action: action, timeOut: timeout}
  this.addMovement = function(move) {

     if (move.action == "RUN") {
        this.run();
        return;
     }

     if (move.action == "HALT") {
        this.halt();
        return;
     }

     if (typeof move.timeOut == 'undefined') {
        move.timeout = 10; //Default to 10ms
     }

     var c = this;

     this.q.push(function(done) {
                setTimeout(function() {
                    c.doMovement(move.action,move.timeOut);
                    done();
                }, move.timeOut);
     });
    }

    this.halt = function() {
        this.q.stop();
    }

    this.run = function() {
       this.q.start(function(err) {
          if (err != null) {
            console.log(err);
          }
        });
    }

    this.doMovement = function(action,timeout) {
        //Todo: this is where we'd talk to the hardware
        console.log(action);
        console.log(timeout);
   }

    this.shutdown = function() {
        //Todo: If we need to shutdown any hardware handles etc.
    }
}

module.exports = new controller();

Controller.png

 

You can see all of the code at https://github.com/Workshopshed/UpcyclingDesignChallenge/

 

Reference

https://devcenter.heroku.com/articles/ssl-certificate-self

https://technet.microsoft.com/itpro/powershell/windows/pkiclient/new-selfsignedcertificate

https://www.sslshopper.com/move-or-copy-an-ssl-certificate-from-a-windows-server-to-an-apache-server.html

https://github.com/mcollina/mosca/wiki/TLS-SSL-Configuration

JsDoc Reference - Paho.MQTT.Client

Run a Script on Edison Boot | Shawn Hymel

 

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

[Upcycle It] Interactive Race Car Driver - Powering Motors

[Upcycle It] Interactive Race Car Driver - Bumper switches and wiring loom

So that I could tell if the car had bumped into anything I wanted to put some microswitches into the bumpers. I had recently stripped down a paper shredder and had stripped out a few useful parts including a couple of micro-switches. Luckily these were the same size as a couple of others I already had (which may have come from my previous shredder).

Microswitches

As mentioned in the discussions I was concerned over the number of I/O used by the car and wondered if it was possible to connect all of the switches on one input. I'd previously seen the idea of using a resistor ladder into an analogue input. However, I wondered if that could be adapted to support multiple buttons. I came up with a schema using the change over connections of the micro switches before realising that I did not have these connections on my two new switches. However, I also realised that I could use a couple of ports, one for the front and one the back. Unfortunately, this means I don't have ISRs on the bumper switches but that can be handled in the software instead.

 

I put the circuit in the simulator again so I could rapidly play with resistor values. I came up with the ratio of R1 = R2, R3 = 2 x R2 which gave the values of 5v, 3.3v, 2.5v and 2.0v for the different switch settings. I had originally used push buttons but then realised I could not press 2 at once in the simulator. Of course, you could also do this with simple maths too. BBC - Higher Bitesize Physics - Resistors in circuits : Revision

BumpersCircuit.png

 

Software for sensors

I did look into using the MCU to monitor the switches but the ADC is handled by the Arduino breakout and the MCU does not handle floating point. So I'm not saying that it's impossible but it is undocumented and there are numerous challenges to resolve.

EdisonAnalogue.png

So I stuck with using MRAA and Node for the Analogue inputs. The code in the "setInterval" function polls the analogue input every 100ms. If it has changed from one of the 4 states then it raises an event which is picked up by the "listener" function, this simply writes the data to the console but in the real car it would cause the car to stop and the driver to say something like "ouch".

 

var mraa = require('mraa');
var events = require('events');

var listner1 = function listner1(value) {
   console.log('Bumper:%d' , value);
}

var eventEmitter = new events.EventEmitter();
eventEmitter.addListener('bumper', listner1);

var previous = -1;
var analogPin0 = new mraa.Aio(0); //setup access analog input pin 0

//Monitor the bumper analogue pin and raise events if it changes
setInterval(function () {
    var analogValueFloat = analogPin0.readFloat();
    var newval = floatToSwitch(analogValueFloat)
    if (newval != previous) {
        eventEmitter.emit('bumper',newval);
        previous = newval;
    }
} , 100);

var BumpEnum = {
  None: 0,
  Left: 1,
  Right: 2,
  Both: 3
};

//Scale the input to one of our 4 values depending on
//which of the two switches are pressed
function floatToSwitch(value) {
    if (value < 0.45) return BumpEnum.Both;
    if (value < 0.58) return BumpEnum.Left;
    if (value < 0.83) return BumpEnum.Right;
    if (value >= 0.83) return BumpEnum.None;
}


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

 

Pins and cables

I came up with the following wiring that allows me to use the grove connections without modification and not need to create any clever split cables to handle front and back.

 

Lights

  • Brake lights - Pin 1
  • Headlights - Pin 5 (PWM)
  • Indicator L - Pin 3
  • Indicator R - Pin 4

Motor

  • Motor Speed - Pin 6 (PWM)
  • Motor 1 Direction - Pin 7,8
  • Motor 2 Direction - Pin A3, A4

From: https://github.com/intel-iot-devkit/mraa/blob/master/docs/edison.md  - AIO pins are treated as 0-5 in mraa_aio_init() but as 14-19 for everything else.
Therefore use mraa_gpio_init(14) to use A0 as a GPIO

Bumpers

  • Bumpers A0 and A1 (split front and back), resistor ladder to be used to allow left and right switches to be independently detected.

Light Sensor

  • Light sensor - A2

Cables (10 needed)

  • Front Lights - D2, D4
  • Rear Lights - D3, UART
  • Motor - D6, D7, A3
  • Bumpers - A1
  • Ambient light sensor - A2

 

So that's pretty much all that can be added so if I need anything else it will have to break out via I2C and need to buy some more cables

 

Assembly

I've started soldering up some of the sub-modules that make up the car.

 

The main drive motors have been fitted with new wires that came from an old PC power supply, the motor drive board has been started and the headlights / indicators have been soldered up. As there are quite so many LEDs for the headlights, I'll use a simple transistor switch to boost the current to those and for the brake lights too.

PCCable.jpg MotorBoardWorkInProgress.jpg HeadlightsAndIndicators.jpg

Reference

tronixstuff.com/2011/01/11/tutorial-using-analog-input-for-multiple-buttons

https://github.com/intel-iot-devkit/mraa/blob/master/examples/javascript/AioA0.js

https://github.com/intel-iot-devkit/mraa/blob/master/docs/edison.md

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

[Upcycle It] Interactive Race Car Driver - Powering Motors

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