Netduino and RC Receivers (I am using a Spektrum AR600) - General Discussion - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Netduino and RC Receivers (I am using a Spektrum AR600)

RC Receiver

Best Answer JamieDixon, 19 March 2013 - 12:29 AM

I was thinking along the same lines.

I got it working with this code:

    public class Program    {        static OutputPort _forwardPort = new OutputPort(Pins.GPIO_PIN_D13, false);        static OutputPort _backwardsPort = new OutputPort(Pins.GPIO_PIN_D7, 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 void inputPort_OnInterrupt(uint data1, uint data2, DateTime time)        {            if (data2 == 1)            {                leadingEdge = time.Ticks;            }            else            {                long currentPulseWidth = (time.Ticks - leadingEdge) / 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;                        }                }            }

 

You can change the output to the analog ports if you want to dim the LEDs.

 

Note that I found a really article on unit testing the Microframework here.

 

Thanks for your help.  I am now going to see if I can use the PWM class to fire to the servo.  Also, my oscilliator will be coming next week...

Go to the full post


  • Please log in to reply
29 replies to this topic

#1 JamieDixon

JamieDixon

    Member

  • Members
  • PipPip
  • 25 posts
  • LocationCary, NC

Posted 07 March 2013 - 06:59 PM

I pulled an old RC receiver out of the closet (Spektrum AR600) and wanted to see if I could use my Netdunio to communciate with it.  The receiver is a 4.8V receiver with 6 outputs (Rudder, Elevation, etc..)  Each output has 3 prongs: Power (+), Ground(-), and Signal. 

 

I got power to the Receiver using the Netduino 3V3 output to Power(+) and Netduino Ground to Ground(-).  The RC transmitter binds successfully to the RC recevier (at least I think so b/c the receivers 'ready' light is lit up).  When I put the Signal from the receiver (elevation output) back to the Netduino via the AnalogIn[0] and deploy  the following code,

        public static void Main()        {            AnalogInput input = new AnalogInput(Pins.GPIO_PIN_A0);            OutputPort output = new OutputPort(Pins.ONBOARD_LED, false);                while (true)            {                Int32 value = input.Read();                Debug.Print(value.ToString());                Thread.Sleep(500);            }        }

 

I get the following kinds of output. 

932
3
10
0
0
2
7
5
7
5
3
11
926
3
6
7
3
911
7
5
0
7
7
0
0
5
2
0
0
929
0
 

When I push the up or down on the elevator stick (and hold it there), the pattern does not change.  I see in the manual that you shouldn't use it if the voltage is under 4.8 so I wonder if that its it?  I can use the 5.0V Ouytput from the Netduino and use a resistor to bring it down to 4.8 but I wonder if I am missing something.  Perhaps RC receivers use digital I/O?

 

Does anyont have experience with this kind of thing?

 

 



#2 martin2250

martin2250

    Advanced Member

  • Members
  • PipPipPip
  • 37 posts
  • LocationGermany

Posted 07 March 2013 - 07:26 PM

a single resistor would probably not help, you should use a voltage divider, assuming the maximum output of the receiver is 5.0V, you should use ~1k as the upper resistor, and ~1.5k as the lower one, this will lower the output voltage to 66% of the original voltage, which for 5V would be 3.3V

 

( GND---// 1.5k /----AnalogIn----// 1k /---Signal in )

 

Greetings



#3 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 07 March 2013 - 09:28 PM

Yes, voltage most likely matters. I would think that you can safely power the receiver with 5V. I'm pretty sure you won't blow it with an excess of only 200mV. If you really wan't to take it down to 4,8V you should use an adjustable voltage regulator with a drop out voltage a bit less than 0.2V or else you will have to feed it more than 5V to uphold an output of 4.8V. You could also use an adjustable step up converter from 3.3V. If you don't have any such regulators, you could construct a 0.2:5 = 1:25 voltage devider, by for example putting a ~24k resistor between GND and the receiver positive supply pin and then putting a ~1k from there to 5V. This should work too as long as receiver power consumption is modest.

#4 Giuliano

Giuliano

    Advanced Member

  • Members
  • PipPipPip
  • 361 posts
  • LocationSimi Valley, CA

Posted 07 March 2013 - 10:18 PM

The receiver battery packs are ususally 4.8v. The receiver specs say it can be power from 3.5 to 9.6V, so it is safe to power with 5V. Keep me posted.

#5 JamieDixon

JamieDixon

    Member

  • Members
  • PipPip
  • 25 posts
  • LocationCary, NC

Posted 08 March 2013 - 12:00 AM

OK, so I plugged in the RC receiver to the 5V output on the Netduino board and it is still working.  The output is the same from the Signal.

 

Every 13-15 ticks it bursts a value.  No matter what I do with the RC transmitter, the values don't change.

 

1) Can anyone tell me what the value from input.Read() is?  Is it a measure of voltage?

2) I have never been down into this level of a RC controller.  Looking at a typical RC plane, each of these outputs from the RC Recevier has 3 components: Power(+) and Ground(-) which I assume sends power to the servio (flaps, aldeons, etc..) and then the signal tells how far the servio should move.  I noticed in the schematic of the receiver that signal is notated with a symbol that looks like a bridge _|-|_.  What is vexing is that nothing I do with the teansmitter seems to affect the values out of Analog.Input.Read()....

 

I then added each of the outputs of the receiver like this:

 

            AnalogInput throttleInput = new AnalogInput(Pins.GPIO_PIN_A0);            AnalogInput aileronInput = new AnalogInput(Pins.GPIO_PIN_A1);            AnalogInput elevatorInput = new AnalogInput(Pins.GPIO_PIN_A2);            AnalogInput rudderInput = new AnalogInput(Pins.GPIO_PIN_A3);            AnalogInput gearInput = new AnalogInput(Pins.GPIO_PIN_A4);            OutputPort output = new OutputPort(Pins.ONBOARD_LED, false);                while (true)            {                Int32 throttleValue = throttleInput.Read();                Int32 aileronValue = aileronInput.Read();                Int32 elevatorValue = elevatorInput.Read();                Int32 rudderValue = rudderInput.Read();                Int32 gearValue = gearInput.Read();                Debug.Print("Throttle="+throttleValue.ToString()+" Aileron="+aileronValue.ToString()                    +" Elevator="+elevatorValue.ToString()+" Rudder="+rudderValue.ToString()                    + " Gear=" + gearValue.ToString());                Thread.Sleep(500);            }

 

And all of the outputs seem to follow some kind of pattern:

 

Throttle=1 Aileron=0 Elevator=0 Rudder=0 Gear=923 Throttle=0 Aileron=0 Elevator=0 Rudder=1 Gear=0 Throttle=0 Aileron=924 Elevator=0 Rudder=1 Gear=0 Throttle=0 Aileron=0 Elevator=0 Rudder=0 Gear=0 Throttle=0 Aileron=2 Elevator=1 Rudder=0 Gear=924 Throttle=1 Aileron=0 Elevator=2 Rudder=3 Gear=0 Throttle=1 Aileron=1 Elevator=0 Rudder=924 Gear=0 Throttle=1 Aileron=0 Elevator=0 Rudder=2 Gear=0 Throttle=925 Aileron=2 Elevator=2 Rudder=1 Gear=1 Throttle=0 Aileron=0 Elevator=0 Rudder=1 Gear=0 Throttle=0 Aileron=0 Elevator=0 Rudder=2 Gear=0 Throttle=1 Aileron=1 Elevator=0 Rudder=1 Gear=0 Throttle=0 Aileron=2 Elevator=0 Rudder=1 Gear=2 Throttle=1 Aileron=0 Elevator=0 Rudder=1 Gear=0 Throttle=0 Aileron=1 Elevator=0 Rudder=1 Gear=0 Throttle=0 Aileron=923 Elevator=0 Rudder=1 Gear=0 Throttle=1 Aileron=1 Elevator=0 Rudder=1 Gear=0 Throttle=2 Aileron=0 Elevator=928 Rudder=0 Gear=0 Throttle=0 Aileron=0 Elevator=1 Rudder=1 Gear=923

Nothing I do with the RC transmitter affects these values.  I then unplugged the wires FROM the transmitter and teh values are the same - so that means that the netduino has some kind of "noise" on the Analog In ports?  Has anyone seen that before?



#6 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 08 March 2013 - 01:51 AM

1. Yes, its a measure that is proportional to the voltage on the pin. Depending on if you got a regular Netduino or an N2, the readings are scaled to a 10 and 12 bit representation respectively. So if you are using a regular Netduino, digitized values span from 0 (zero) up to 1023 corresponding to 0 to 3V3. So if the signals are 5V peak, your ADC will max out at 3V3 and possibly even burn since the analogue pins are not 5V tolerant. It could also be voltage levels are very small. Either way you would need some external circuitry to scale the voltage levels so that they are between 0 and 3V3, if they're not already within that range that is. This will make sure you use the full dynamic range of the signals. If I where you, I would take a 3V3 source and connect to ground via a potentiometer as an adjustable voltage divider. You can then verify that the ADC of your Netduino is actually working as it should by connecting pot output to an analogue pin and a multimeter while turning the pot and keeping an eye on both the multimeter and the debugger output. To make debugger output more readable, you could multiply values with 3.3 and devide by 1023 which will give you the voltage instead. 2. If part 1 checks out, use the multimeter (or preferably an oscilloscope) to measure the signal levels from the receiver as you move the sticks or what have you on the transmitter. IMHO it would probably be easier if you focused on one signal at a time. What do you know about the signals, are they supposed to be purely analogue and proportional or are they perhaps modulated somehow? Are these the signals that would nomally go to a servo? Could the signals perhaps be momentary and that you read them too seldom or out of sync? Sorry for all the suggestions and questions, I'm just keen on trying to understand and also quite interested since I think it's a cool project that has a lot potential possibilities to it.

 

EDIT: When looking at the manual just now, I found the below symbol (maybe it's what you meant by "bridge" earlier?)

Attached File  receiver.png   64.43KB   10 downloads

This could indicate that output is actually PWM (pulse width modulation) and not proportional analogue. If so, it means the receiver output is a pulse train (square wave) modulated on a carrier frequency with variable duty cycle (percentage of the period where the signal is high). Depending on exactly when you sample the output, you would "hit" either a low or high part of the wave which would typically result in erratic readings. This would explain a lot.

 

The solution would be to convert the signal to analogue. This can be done using a hardware low pass filter (using a resistor and a capacitor on each channel) with a cut off frequency about a 10th of the carrier frequency.

 

It might also be possible to do several readings per channel and calculate the RMS (root mean square) of those. This is somewhat simpler as it can be done entirely in software. Create a cyclic buffer with room for, say 256 readings for each channel. Sample each channel, one after another (like you do now) and store values consecutively in each cyclic buffer.

 

After the first 256 readings you start calculating a sliding RMS from all 256 values of each buffer. You do this each loop round and the resulting RMS values would then be your analogue readings and you have now created a digital filter. It may also work calculating the sliding average instead of RMS. This would be less time consuming since there is a clever way to do this.

 

A really long post. Sorry  :)



#7 JamieDixon

JamieDixon

    Member

  • Members
  • PipPip
  • 25 posts
  • LocationCary, NC

Posted 08 March 2013 - 12:17 PM

Thanks for the suggestions.  I used the following code and out the analog pin to use 3.3 volts

        public static void Main()        {            AnalogInput input = new AnalogInput(Pins.GPIO_PIN_A0);            Double inputValue = (double)input.Read();            double voltage = (inputValue * 3.3) / 1023;            while (true)            {                Debug.Print(voltage.ToString());            }        }

 

When I used 3.3 V and used the formula provided, I got a consistant reading:

0.012903225806451613

0.012903225806451613
0.012903225806451613
0.012903225806451613

 

I unplugged it and re-plugged it back and got a different consistant number:

0.0096774193548387084
0.0096774193548387084
0.0096774193548387084
0.0096774193548387084
0.0096774193548387084

 

So the recevier needs 4.8 volts and the Netduino can only have 3.3 coming back into the Analog pin?

 

I also chceked out some other articles that seem to be doing what I am doing:

 

http://pastebin.com/jrJedzsM

http://forums.netdui...nd-control-esc/

 

I tried using an interrupter port on the DigiitIO but the event handler never fired:

 

        private static void ReadInputViaInterruptPort()        {            InterruptPort port = new InterruptPort(Cpu.Pin.GPIO_Pin0, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);            port.OnInterrupt += new NativeEventHandler(port_OnInterrupt);        }        static void port_OnInterrupt(uint data1, uint data2, DateTime time)        {            Debug.Print(data1.ToString() + " " + data2.ToString());        }

 

 

I will try your other suggestions in a bit.  I don't have an oscilliscope - do you have a recommendation?

 

 

 

 


 



#8 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 08 March 2013 - 01:14 PM

Assuming you jerked the stick :o while doing readings, levels look weird and seems practically zero all the time. If it's PWM, one would think that you'd be bound to hit a high pulse at some point. It also surprises me that the digital pin won't fire interrupts - this would mean the signal never reaches a high TTL level.

 

Are you absolutely sure the values never changed over time?

 

What did your multimeter say? I guess you could try switching the multimeter to AC mode.

 

Yes, Netduino hardware specs say only digital pins are 5V tolerant so this ought to mean analogue pins are not. I use the mini, it has the same MCU as the regular Netduino and it accepts a maximum of 3V3 on the analogue pins.

 

All in all I begin to suspect the receiver doesn't give any real output at all. Are you sure it has been paired correctly?

 

It suddenly hit me that, since it's likely a switcher and could be it must have a small load on the outputs. Connect 10k between the channel signal output pin and ground to see if that helps?

Attached File  receiver.png   69.96KB   14 downloads

 

My oscilloscope is a Rigol DS1052E which is great value for money (and can be safely hacked to 100Mhz). A while ago they were on sale and probably still are since they have been superceeded by a new model providing only little advantage. This guy knows what he's talking about:

 

http://www.youtube.com/watch?v=LnhXfVYWYXE

 

It's about 340 USD and probably less if you start digging. There are of course much cheaper, like small handheld ones and there are several posts on choosing a scope here in the forum.



#9 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 10 March 2013 - 12:51 AM

Hi Jamie, just curious of how this went for you.

 

It wouldn't surprise me the least bit if it turns out the receiver actually needs a little load on the outputs. Have you tried it?



#10 JamieDixon

JamieDixon

    Member

  • Members
  • PipPip
  • 25 posts
  • LocationCary, NC

Posted 10 March 2013 - 05:32 PM

hanzibal:

 

I am confused about the schematic you put into the post.  You have 1 wire coming from A0 to the Signal port and then splitting that wire to a 10K resistor and then going to ground.  Is that correct?

 

Also, I <think> that the signal is PWM based on this post. 



#11 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 11 March 2013 - 08:28 PM

Yes that is it, the only difference from how you have had it connected before should be that there's now a 10k resistor from A0 to ground. This will apply a small load to the reciver THRO output pin while sampling it through the A0 analogue input pin of your Netduino.

Naturally, ground of the receiver should be connected to ground on the Netduino but I assume this has been the case all along, right?

Could you please draw an image showing how you have it all wired up?

EDIT: Yes, judging from the code you referred to, it seems very much like PWM and that would (like I said earlier) explain everything except the fact that you did not get any interrupt when you tried a digital input pin on your Netduino. So now, I'm suspecting you could have it wired up wrong.

Also check out this article describing how digitalky modulated servos work. The width of the pulses vary between 1000us and 2000us which matches the expected value span for the channel test code that you linked to.
http://www.servocity...rvos_work_.html

Either your reciver is broken or it's not wired up correctly or it hasn't been properly bound to the transmitter.

#12 thepilotfish

thepilotfish

    Member

  • Members
  • PipPip
  • 12 posts

Posted 11 March 2013 - 10:17 PM

Hello Jamie,

 

Your original readings look right. The standard analog servo expects a pulse every 20ms. It is the duration of the pulse that matters (<1.5ms vs. > 1.5ms - see the signal graph in the link above). Accounting for the analog input noise, you can consider your <10 values as low level and your >900 values as high level. Since you are reading the input once every (roughly) 500ms, you are probably randomly (at resonance frequency?) hitting the pulse.

 

This thread has more details on the challenges/limitations.

 

Sorry - I know I am not much of a help... I haven't seen a reliable and purely software solution for Netduino - if anyone has one, I'd be curious to read about it too...

 

 

 

Chris

www.projectpilotfish.com



#13 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 12 March 2013 - 03:38 AM

@Chris: Now that we know that the signal is in fact PWM, trying to read it using the ADC is just wrong. The signal should be read using a digital pin with an interrupt handler attached to it.

@Jamie: I'm sorry if I seem to have lead you astray before but without knowing the nature of the signals (until very recently) we've had to do some trial and error using different approaches. I find it very disturbing the AR600 manual does not say anything about the charactistics of the signals.

Anyway, with a periodicy of 20ms the frequency is 50Hz and the Netduino should be able to cope. To determine the length of each pulse, you can calculate the time difference between any two consecutive interrupts where the first is on a high edge and the second is on a low edge. This can be done since interupts are buffered and time stamped correctly.

Could you please try a digital pin again (no resistor) and configure the interrupt to fire on both edges. Connect only ONE single signal for now and have the main thread sleep indefinately using Sleep(Timeout.Infinite).

Put a breakpoint in the interrupt handler.If you are really not seeing any interrupts at this point, it could be pulses are not high enough for the Netduino to consider it a digital "1". If so, you will have to boost levels to 3.3V which can be done using an NPN transistor.

When you get this right, you can the start decoding pulse lenghts, again according to this article:
http://www.servocity...rvos_work_.html

When you got this working too, you will face the next problem; how to read the other 5 channels as well. I got a few ideas that we can discuss when you've gotten that far.

Until then, good luck!



#14 JamieDixon

JamieDixon

    Member

  • Members
  • PipPip
  • 25 posts
  • LocationCary, NC

Posted 12 March 2013 - 11:39 AM

So I went down to the local hobbyshop and bought this and this.  I then hooked them up to the RC receiver and confirmed that my prior experiments didn't break anything - the servo moves when I push the RC transmitter stick.

 

I then took off the battery pack and hooked up the netduino as the power supply.  When I used the 3.3V, the servo moved most of the time.  When I used the 5.0V, the servo worked all of the time.  I guess that extra .2Volts wont burn out this receiver (yet)?

 

In any event, I then put aligator clips on the signal line and put my multimeter on that line.  I set the multimeter to 200M direct current and occasionally the multimeter would read .01 or .02, even if the RC transmitter stick wasn;t moving.  oving the stick didn't seem to affect those values.  (I would include a photo but I haven't figured out how to do that with this web interface, different topic)

 

I wonder if the multimeter doesn't have enough precision to measure the bursts of electricty?

 

I'll take a look at what hanzibal and Chris suggested next...

 

 



 



#15 JamieDixon

JamieDixon

    Member

  • Members
  • PipPip
  • 25 posts
  • LocationCary, NC

Posted 12 March 2013 - 11:45 AM

I am reading that wikipedia article that Chris linked to.  Great find - thanks.  I have 1 question about the signal circuit.  The burst of electricty that is sent down the signal wire - I assume it uses the ground wire to complete the circuit?  So, in effect, the ground wire is being used by BOTH the power wire and the signal wire? The Power circuit is a continous 4.8/5.0 volt circuit with signal circuit having an occassional, voltage and duration yet to be determined, circuit?



#16 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 12 March 2013 - 01:02 PM

Yes, ground is the same through out the whole circuit. Ground is the "return" path for all current just like you said.

 

It's just like you assumed about power and signal. Power is continuous while the signal keeps sending a pulse every ~20ms. The width of each pulse varies depending on the transmitter lever (stick or what have you) and determines the angle of the servo.

 

I suggest you connect the Netduino while the servo is in place, this way you get a visual confirmation of what is happening.

 

To make the circuit, you need to high jack the signal and ground wires of the receiver (or servo side which ever is the easiest). You then connect the signal wire to a digital input pin of the Netduino and the ground of the servo/receiver goes to ground of the Netduino. You will not be high jacking the power wire.

 

You can then try and write an application that works like what I described in this earlier post:

http://forums.netdui...600/#entry47052

 

If you plan to do a lot of stuff like this, you should really consider getting an oscilloscope. When I got mine, I went "I was blind and now I can see". Yes, it's really and extremely useful and versatile tool!



#17 JamieDixon

JamieDixon

    Member

  • Members
  • PipPip
  • 25 posts
  • LocationCary, NC

Posted 12 March 2013 - 07:03 PM

So a quick question about the Netdunio hookup before I start wirting code.  I have power coming from the netduino 5V to the RC receiver.  I have the Ground coming from the same bank of blue ports to the RC recevier.  I have the signal wire coming from the RC receiver to the Netduino Digital I/O port 0.  Do all of the blue banks' ground connect?  Do I need to run a 4th wrie from the RC recevier to the Ground on the digital I/O side?

 

Does that make sense?



#18 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 12 March 2013 - 08:06 PM

The netduino is wired up correctly to the receiver, you don't need to connect any more wires for the signal. You only need one ground wire because ground is common return path for everything else (just like the receiver's power and signal share a common ground). As for powering the reciver with 5V from your Netduino this might be a bad idea. The receiver in turn powers the servo which might require a bit of power, especially if you apply load like having it pull something that requires some force. Assuming the Netduino in turn is powered by USB - the USB port of your computer can supply a maximum of 500mA which might be insufficient possibly inflicting damage to the USB controller of your PC. You should check the servo specs for its current draw when moving without a load. It might very well be that its only like 100mA and then your fine. If its significantly more, you need an external 5V power supply capable of delivering the required current. My guess is that its ok but you should generally avoid powering motors from USB. Why not use the brand new battery instead? That would keep you on the safe side in terms of power requirements.

 

EDIT: If you choose to use an external power source (battery or 5V adapter) it should be connected to the receiver and not to the Netduino 2.1mm barrel connector. You can still have USB connected to your host PC but you must remove the wire from Netduino 5V  to the receiver (keep the ground wire though).



#19 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 16 March 2013 - 04:35 AM

Jamie, I was inspired by your project and so I started working on the opposite. Picked up a cheap servo yesterday to see if I can control it with a micro. When trying to find out about voltage levels, I came across this article that explains it all pretty well:

http://www.pololu.co...rface-in-detail

I've actually got my servo moving but it's acting much like it had too much to drink :-)

#20 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 17 March 2013 - 08:31 AM

The servo has now sobered up and can walk the line. Quite fun to look at. A few details that might interest you Jamie: I used a rather powerful digital servo for 4.8 - 6V with a separate USB cable to power it from 5V. This worked well as I applied no mechanical load to the servo arm. However, I couldn't use the same USB supply also powering the board since this caused brown-outs resetting the board whenever the servo attempted to move. I found that pulse voltage (height) had to be at least 2.8V or the servo would not react at all. The servo has virtually no power draw on the signal wire. Also, the pulse width varying from 1.0ms to 2.0ms only allows a ~90 degree rotation, e.i. -45 to +45 degrees originating from the center with a pulse width of 1.5ms. I tried to go beyond these limits to increase the range (this was mentioned in the article) but in efforts to do so, the servo gears broke when it tried to move beyond its own limits. This risk is also mentioned in the article (ha,ha) but I find it weird that servos generally don't have any built-in protection against this since it should be quite easy to implement.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.