The Eject-A-Bed: Part 2

Now that we have a way of controlling the bed via a Netduino, we need a way of controlling the Netduino.  We thought about different scenarios – hacking into an alarm clock, a phone app, some kind of light sensor, etc…  In all of these scenarios, it made sense to make the Netduino Ethernet aware so I went and bought a new Netduino plus.  The two day wait for Amazon prime reminded me how we have come full-circle with getting our goods.  I am going to re-write the lyrics from the Music Man’s Well’s Fargo Wagon to the Amazon Wagon

O-ho the Am Azon Wagon is a-comin‘ down the street,

Oh please let it be for me!

O-ho the Am Azon Wagon is a-comin’ down the street,

I wish, I wish I knew what it could be!

In any event event, with the Netduino plus, I could send signals to the Netduino to move the bed up and down.  I checked Dan Theyer’s post about how build a solid class to cover Ethernet communications and I checked out this article to get a “Hello World’ Ethernet project up and going.

I decided to start with the ground up happy path using the ‘Hello World’ project.  To that end, I added a socket instance to the project

I then add the SetUpWebServer method like so:

And the ListenForRequest like so:

You will notice a lack of  exception handling and threading.  Typically, the _socket.Accept() method should be on the main thread and then handling the message should be done on a separate thread so the _socket can get to listening the next message as fast as possible.  However, since the servo is directly tied to individual messages, I thought it was better to make the entire execution serial.  Plus, I am lazy.

In any event, once the Netduino gets a request, it then needs to adjust the servo:

And the actual controlling of the servo we have seen before:

There can be some confusion about the word “duration”.  duration with a little ‘d’ means how long the servo stays in the non-straight position – effectivly how long the bed is moving.  Duration with the big ‘D’ means the location of the servo as it rotates around the center – how far the servo moves.  When I make this ready for prime time, my covering class will fix this ambiguity because I am a big believer in domain-unique language.  I will also be copying much of Dan’s code.

In any event, I also created a response method so the requestor can see something:

So now when I send a browser request on my local Ethernet:

And sure enough, we can control the servo with my web browser

And then put together and using the browser in my phone:

Now if there was only a way to speed up the motor so I can launch my kid out of bed in the morning with more force….

The Eject-A-Bed: Part 1

Some people are born to greatness.  Some people have greatness thrust upon them.  Some people find greatness on Craig’s List.  A couple of months ago, I was killing some time searching for mechanical devices on Craig’s List when I ran into this:

So of course I picked it up and put it into the garage.  An interesting side note is that the seller got it at the UNC surplus warehouse.  Apparently, you can get really good deals on used medical and university equipment there.  I need to add it to my Christmas shopping rotation.

My daughter, Sonoma, and I first wanted to understand how the controller works.  We first thought that the controller used PWM so we hooked up our Oscilloscope to the two metal wires that travel from the controller to the bed’s motor.  We moved the controller up and down but no signal was being recorded.  Sonoma then noticed that the “wire” was a hollow tube.  Taking a wild guess, we blew down the pipe.  Sure enough, that made the bed move

So now we had to figure out how the controller moved air up and down the pipe.  We opened the controller and there is a small bellow that attaches to the pipe.  Press the controller on 1 side and air is forced down the pipe, press the controller on the other side and air is sucked up the pipe.

So we batted around ideas about how to push air up and down the pipe – ideas included using a small electric air compressor, some kind of mechanical pressure plate, etc…  We then decided to try and gluing a servo to the switch and controlling the movement that way.  However, we couldn’t figure how to attach the servo to the existing plastic switch.  So we decided to build our own switch – we used  my son’s erector set to create the harness for the bellows

and we are now into the coding piece of it. 

Step one was to confirm that I hooked up my scope to the Netduino correctly.  I modified the Blinky code (Netduino equiv to ‘Hello World’ to add a pulse on one of the output ports:

Sure enough, I am seeing the pulse.

I then wired PWM class to see if the output was what I expected:

and sure enough I am getting a pulse every 20 milliseconds with a length of 1 millisecond.

A word to the wise, do NOT use the Cpu.PWMChannel enum as it does not fire – use PWMChannels enum

So now it is a question of hooking this up to my servo.  It is a standard RC plan servo.  I have no idea about the period, pulse and/or duty cycle of this specific servo but it seems that there is a standard in the RC community that periods are 20 MS (as confirmed when I worked on the RC lawnmower) and the pulses are:

• 1 MS = 180 to one direction
• 1.5 MS = Top Dead Center
• 2.0 MS 180 to the other direction

The problem is that the period is an uint – so I can’t set it to 1.5 MS.  I then learned about Duty Cycles where I can pass in a double and have the period adjust.  Basically:

• 1 MS = Duty Cycle of 5%
• 1.5 MS = Duty Cycle of 7.5%
• 2.0 MS = Duty Cycle of 10%

So to test this, I set up the PWM to have a 20 MS period, a 1 MS duration, and a Duty Cycle of 1.0. 

1. uint period = 20;
2. uint duration = 1;
3.  
4. PWM servo = new PWM(PWMChannels.PWM_PIN_D5, period, duration, PWM.ScaleFactor.Milliseconds, false);
5. servo.Start();
6.  
7. while (true)
8. {
9.     servo.DutyCycle = 1;
10. }

The problem is that this does not work.  If you use the period/duration constructor for the PWM class, you cannot set the DutyCycle property and get the desired effect.  What you have to do with that constructor is to use the duration property.  So to get the non-integral units, I needed to change the PWM.ScaleFactor to Microseconds and start thinking of things in terms of thousands.  Once I did that, I spent some time figuring out the TDC and the max left and right:

I then hooked up the servo to the bellow controller:

and set up a program to activate the bellows for 2 seconds:

and success.

Capturing PWM with a Netduino (Part 2)

So I decided even if I can’t figure out what the signals are saying, at least I could capture the PWMs as they came into the Netduino.

Knowing that the PWM pulse occurs every 20MS, the duration of the pulse determines the direction of the servo.  For example, if the pulse is 2MS, the servo should move up.  If the pulse is 1MS the servo should move down.

The Netduino allows you to capture the leading edge of the pulse and the trailing edge of a pulse.  Theoretically. if you measure the leading edge of pulse 1 to the leading edge of pulse 2, the difference will always be 20MS.    However, the difference between the trailing edge of the pulse and the leading edge of the next pulse (or the trailing edge of the next pulse) will vary depending on the RC receiver’s signal.

That means I need a way to capture the 2 edges of the pulse, calculate the difference between them, and then do something with that information (altering a servio’s position for example).

My first approach was like this

public static void Main()
{

    InterruptPort inputPort = new InterruptPort(Pins.GPIO_PIN_D0,
        true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);

    inputPort.OnInterrupt += new NativeEventHandler(inputPort_OnInterrupt);

    Thread.Sleep(3000);
}

static long leadingEdge = 0;
static void inputPort_OnInterrupt(uint data1, uint data2, DateTime time)
{
    if (data2 == 1)
    {
        leadingEdge = time.Ticks;
    }
    else
    {
        long pulseWidth = (time.Ticks - leadingEdge)/1000;
        Debug.Print(pulseWidth.ToString());
    }
}

With the results like this:

I expected to see 20MS, not 14.  In any event, I then ran the same program and moved the stick up and down.  Sure enough, the pulse modulated.

However, it did not modulate in discrete values.  Rather, it rose and dropped as if it was analog.

I then added this code to evaluate the rise and fall of the PWM:

static OutputPort outputPort = new OutputPort(Pins.ONBOARD_LED, false);

public static void Main()
{
    InterruptPort inputPort = new InterruptPort(Pins.GPIO_PIN_D0,
        true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);

    inputPort.OnInterrupt += new NativeEventHandler(inputPort_OnInterrupt);

    Thread.Sleep(Timeout.Infinite);
}

static long leadingEdge = 0;
static long priorPulseWidth = 0;
static void inputPort_OnInterrupt(uint data1, uint data2, DateTime time)
{
    if (data2 == 1)
    {
        leadingEdge = time.Ticks;
    }
    else
    {
        long currentPulseWidth = (time.Ticks - leadingEdge) / 1000;
        long pulseWidthChange = currentPulseWidth-priorPulseWidth;
        if(pulseWidthChange > 0)
        {
            outputPort.Write(true);
        }
        if(pulseWidthChange < 0)
        {
            outputPort.Write(false);
        }

        priorPulseWidth = currentPulseWidth;
    }
}

Sure enough, the LED went on when I pushed the stick up and turned off when I pulled the stick down – mostly.  I think that I need to smooth out the calculation so that I don’t capture each pulse – perhaps every 5th pulse. 

But the behavior is sporadic.  When I pull the stick down and leave it there, the LED sometimes blinks on and off.  Then it hit me as I was writing this – the reason why is that once the stick says still, the pulse still fires and the value is greater than the value when I was pulling the stick down.  Also, when the stick gets “pinned” to either Max up or down, the LED blinks rapidly.  I need to investigate that more.

So I then hooked up 4 digital outputs to represent the up/down of the throttle and the left/right of the turn. 

I then added the following code to set up the 2 inputs and the 4 outputs:

static OutputPort _forwardPort = new OutputPort(Pins.GPIO_PIN_D8, false);
static OutputPort _backwardsPort = new OutputPort(Pins.GPIO_PIN_D9, false);

static OutputPort _leftPort = new OutputPort(Pins.GPIO_PIN_D10, false);
static OutputPort _rightPort = new OutputPort(Pins.GPIO_PIN_D11, false);

public static void Main()
{
    InterruptPort leftStickPort = new InterruptPort(Pins.GPIO_PIN_D0,
        true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);
    leftStickPort.OnInterrupt += new NativeEventHandler(leftStickPort_OnInterrupt);

    InterruptPort rightStickPort = new InterruptPort(Pins.GPIO_PIN_D1,
        true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);
    rightStickPort.OnInterrupt += new NativeEventHandler(rightStickPort_OnInterrupt);

    Thread.Sleep(Timeout.Infinite);
}

I then added the following code for the left stick:

static long rightStickLeadingEdge = 0;
static void rightStickPort_OnInterrupt(uint data1, uint data2, DateTime time)
{
    if (data2 == 1)
    {
        rightStickLeadingEdge = time.Ticks;
    }
    else
    {
        long currentPulseWidth = (time.Ticks - rightStickLeadingEdge) / 1000;

        switch (currentPulseWidth)
        {
            case 18:
                {
                    _forwardPort.Write(true);
                    _backwardsPort.Write(false);
                    break;
                }
            case 17:
                {
                    _forwardPort.Write(true);
                    _backwardsPort.Write(false);
                    break;
                }
            case 16:
                {
                    _forwardPort.Write(true);
                    _backwardsPort.Write(false);
                    break;
                }
            case 15:
                {
                    _forwardPort.Write(true);
                    _backwardsPort.Write(false);
                    break;
                }
            case 14:
                {
                    _forwardPort.Write(false);
                    _backwardsPort.Write(false);
                    break;
                }
            case 13:
                {
                    _forwardPort.Write(false);
                    _backwardsPort.Write(true);
                    break;
                }
            case 12:
                {
                    _forwardPort.Write(false);
                    _backwardsPort.Write(true);
                    break;
                }
            case 11:
                {
                    _forwardPort.Write(false);
                    _backwardsPort.Write(true);
                    break;
                }
            default:
                {
                    _forwardPort.Write(false);
                    _backwardsPort.Write(false);
                    break;
                }
        }
    }
}

Sure enough, moving the stick and down saw the expected response from the LEDs.  I went to test the right/left stick

and that also acted as expected.  I then hooked up a relay module to the output and used a higher-voltage power source (the relay can go up to 250) and a small light.  Here is the final rig (note that I am using the Netduino 5.0V for the power source of the RC receiver):

Sure enough, I can now control standard household electrical currents using a RC transmitter and receiver.

Capturing PWM on a Netduino

I have been trying to send signals to my Netduino from a R/C transmitter and capture and analyze those signals.  To that end, I have a Spektrum AR600 RC transmitter and receiver.  My first stop was the Netduino forms where there was one very helpful person named Hanzibal who answered my questions.  I also had to use this great article that explains how PWM works in an RC unit.

Basically, the RC receiver sends a pulse of electricity every 20 MS.  This pulse will one of three lengths: 1 millisecond, 1.5 millisecond, or 2 milliseconds.  As I understand the article, 1.5 milliseconds means that servo should stay in the same position it is currently in (do nothing), 1 millisecond means that it should move down a given number of degrees and 2 milliseconds means that the servo goes up a given number of degrees.  The servo itself determines the turn rate and if the servo is at its max, it will ignore the signal.

My first challenge is to set up my hardware that will:

1. 1) not destroy the hardware I am using
2. 2) capture the PWMs

Thanks for Hanizbal and some significant trial and error, I set up my Netduino like so:

You will notice that the RC receiver is powered by a 4.8 V battery pack versus the 3.3V or 5.0V output of the Netduino.

Some of the things I learned are:

You don’t need a ground from the RC receiver to the Netduino board.  The only wire you need to connect is the Signal wire from the RC receiver to the Digital I/O port.

This is not completely fool-proof.  Sometimes when I deploy with the RC receiver connected to the board, I get this:

I found that unplugging the Netduino cord and plugged it back into the Netduino, the code published.

With this in mind, I jumped into Visual Studio fired up a Netduino project.  I first looked at the PWM class

The problem is that the PWM class does not have a GetPulse method or EventHandler.  This is a limitation that is not present in the Arduino as documented in this post.

I then looked at the Interrupt Port class like this person did.  I created some code like this:

public static void Main()
{

    InterruptPort inputPort = new InterruptPort(Pins.GPIO_PIN_D0,
        true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);

    inputPort.OnInterrupt += new NativeEventHandler(inputPort_OnInterrupt);

    Thread.Sleep(3000);
}

static void inputPort_OnInterrupt(uint data1, uint data2, DateTime time)
{
    Debug.Print(data2 + ":" + time.Millisecond + ":" + time.Ticks);
}

When I ran it with the RC receiver unplugged I got this:

Done.

Waiting for debug commands…

The thread ‘<No Name>’ (0x1) has exited with code 0 (0x0).

So the port was not receiving any signals or generating any kind of false signal.

When the RC receiver was plugged into the port, I got:

1:273:128752416062731306

0:274:128752416062743466

1:295:128752416062957226

0:296:128752416062969386

1:318:128752416063183360

0:319:128752416063195520

1:340:128752416063409280

0:342:128752416063421653

1:363:128752416063635413

0:364:128752416063647573

1:386:128752416063861333

0:387:128752416063873706

1:408:128752416064087466

I then fiddled around with the InterruptMode and this is what I found:

• InterruptEdgeLow= 0
• InterruptEdgeLevelLow= None
• InterruptEdgeHigh= 1
• InterruptEdgeLevelHigh= None
• InterruptEdge=Both 1 && 0
• InterruptNone= Exception

So looking at the values of the interrupts, I can’t use time.Milliseconds because it is an Int32 – it doesn’t have the level of precision to read 1.5 MS.

I then took this dataset and calculated the difference in ticks between the 0 and the 1 for each group:

With 10,000 ticks in a millisecond, it means the neutral pulse is 1.2 MS, not 1.5 MS as I initially thought.

This looks promising because at least it appears to be consistent

The battery pack supplying the 4.8V to the RC receiver then died.  I disconnected the battery pack and plugged the receiver into the Netduino 5V output and ran the same experiment again:

So the Period Length depends on the amount voltage coming in.  Also, it the difference is no longer consistent.

I decided to run 1 more experiment – push the stick up and down with the 5V power source:

Sure enough, The PW does change.  The range is from 1.0016 to  2.  The problem is that there is a wide range of possible values for the Pulse Width:

I was expecting only 3 values.  This is showing values 1.0, 1.1, 1.2, etc…  Without a discrete value, there is no way of determining if the stick is going up or down – unless perhaps I can determine that anything under 1.5 is down and above is up?  More hacking is in order…