Paul Newton - Viewing Profile: Likes - Netduino Forums - Page 2
   
Netduino home hardware projects downloads community

Jump to content

  2. → Viewing Profile: Likes: Paul Newton

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.

Paul Newton

Member Since 13 Nov 2011
Offline Last Active Aug 12 2016 04:20 PM
*****

#48785 Stepper Synchronisation (CNC)

Posted by Paul Newton on 27 April 2013 - 06:27 AM

Hi Meister, You could synchronise "stepper motors" by driving a motor shield from the outputs of a 74HC595 shift register. Any number of outputs could be chained together in groups of 8, loaded via the Netduino's SPI, and all updated on a single strobe. This would give perfectly synchronised output changes. Hope this helps - Paul


#48086 Delay interruption handling

Posted by Paul Newton on 05 April 2013 - 06:17 PM

Hi,

 

(I like the way the new forum tells you when someone else posts a reply while you are typing - Hi Dave!)

 

I don't know if this is suitable for your project:

 

How about having a five or ten minute periodic timer whose event handler enables the GPIO interrupt.

When the GPIO interrupt event handler goes off, it immediately disables further interrupts - this way .Net is not bombarded by lots of interrupts. Having done that, it can signal the rest of your code that a pulse has been seen.

 

This scheme would only respond to the first interrupt in every five or ten minute window of time.

 

Paul




#47716 Building a Set of Netduino 2 & Netduino 2 Plus Tutorials to share

Posted by Paul Newton on 29 March 2013 - 07:48 AM

Hi Dave, Nice idea. I'm never sure about starting something new when there are so many other places that have tutorials and projects. I think there is a big difference though when it is organised by someone who spends as much time as you do helping others. Good luck on this! Could you add the following topics: - port expansion via SPI using 74595 and 74165 - H-bridge motor control Paul


#47715 need help!

Posted by Paul Newton on 29 March 2013 - 07:33 AM

Is this project part of an academic course?


#47691 Modem does not respond to AT command

Posted by Paul Newton on 28 March 2013 - 06:21 PM

Hi, Welcome to the forums. Modems have a number of parameters that can be set by sending AT commands. On devices I have used in the past, this has included echo of commands that you type. So it is possible that you have turned off the echo. In the first instance, try checking the modem's manual for available commands. I used to know quite a few command off by heart, but have not had to use them for a few years now A complete guess try ATE=1 Hope this helps -Paul EDIT Did a quick google search: ATE1 for echo ON and ATE0 for OFF.


#47647 Analog input interrupt

Posted by Paul Newton on 27 March 2013 - 06:44 PM

Hi,

 

The Netduino does not have an analogue interrupt capability.

 

To generate an interrupt when an analogue voltage reaches a certain level, you would need to use a voltage comparator chip (or an op-amp) to compare the analogue voltage with a trigger voltage and then connect the comparator output to a normal interrupt input.

 

You would probably set the trigger voltage using resistors or a potentiometer. If you wanted to be really clever, you could set the trigger voltage using a DAC whose voltage is programmed from the Netduino.

 

Hope this helps - Paul




#45674 Netduaders: an Invaders-like game for Netduino (Plus) 2

Posted by Paul Newton on 17 February 2013 - 07:03 PM

OK, so now we need a forum member called "Space Invaders" to make us a "Super Mario" game!




#45616 is the next new netduino hardware has a 176 pins version?

Posted by Paul Newton on 16 February 2013 - 10:00 AM

After your last comment I am not sure if you realise that the 74HC595 can be driven very fast using the built in SPI port.

There is no need to write a loop in software, just set a byte or an array of bytes and start the transfer.

The hardware does the loop so it is much faster than a software loop.

 

The Netduino software does not allow you to write a byte to 8 GPIOs (without creating a collection of pins), so with high numbers of GPIO, you need lots of function calls to set all the pins. With high numbers of pins you might even find that the SPI method is quicker!

 

Have a good weekend!




#45528 Newbie trying to deciede where to start and what to buy.

Posted by Paul Newton on 14 February 2013 - 09:09 PM

I would recommend going for an all in one kit.

 

(Note that I am biased towards the normal Netduinos rather than the go.)

 

I think a good kit should have most of the following:

A bread board, Jumper wires, selection of LEDs (including a 7 segment or matrix display), an LCD module, switches/buttons, potentiometer(s), some analogue sensors such as flex resistors, maybe an IR range sensor, an RC servo, some transistors, a relay, a sounder, and a shift register.

 

The most important item though is some simple lessons on how to use each one and suggestions for combining them. A good book will give you the sparks for the ideas of where you want to go next.

 

As for the choice between the normal Netduino family and the Go, I think it comes down to taste, cost, and how practical you feel. I like to use the real components rather than plug in someone else's modules. But, having said that, the go does have the shield base if you start with modules and then decide to move on.

 

Above all else - remember its supposed to be fun!




#45262 Safe Way to power netduino with 5v Regulated Supply

Posted by Paul Newton on 10 February 2013 - 07:28 PM

Yes, you can connect a USB cable at the same time as supplying power into the Vin/barrel input.

There is a transistor that disconnects the USB's 5V line when Vin is available.

Paul




#44827 Resistor Value for RGB LED

Posted by Paul Newton on 03 February 2013 - 11:55 AM

Use one of each! A pnp and an npn.

 

The npn and pnp transistors need current to flow to turn them on.

 

That means that for an npn we need 0.7V plus the common cathode LED forward voltage (3.2V worse case), so we need to drive the base with 3.2V + 0.7V = 3.9V to get the current to flow into the base and turn the transistor on. That's too high for the Netduino outputs to reach.

 

For a pnp, we just need to provide a voltage 0.7V below the emitter, so with a 12V supply that easy for a Netduino output, unfortunately its too easy. The 3.3V high voltage level for the Netduino is also going to give a path for the current to flow out of the base to ground, so we can't shut off the transistor.

 

Solution 1, is to use the tri-state output mode of the Netduino. When the GPIO pin is set to tristate, no current can flow in or out of the pin, so this could be used with a pnp transistor. When the transistor needs to be on, set the output low, when it needs to be off, set it to tri-state.

There are two reasons this is not going to be useful to you:

1 - I don't think you can set a PWM to operate in tri-state mode.

2 - With the 12V supply, when the pin is set to tri-state, the voltage at the GPIO will be pulled up to near 12V via the transistor's base. The Netduino will not like this.

 

Solution 2, is to use an npn transistor to turn on a pnp transistor.

Here the npn transistor is wired up normally. The collector goes to the base of a pnp transistor via a resistor. Now when the npn is turned on, current will flow from the pnp's base to ground turning on the pnp. When the npn is off, no current can flow, so the pnp will be off.

 

Paul

 

 

Attached Files




#44686 Transistor not working with 12V

Posted by Paul Newton on 31 January 2013 - 09:09 PM

Hi Guys, I'm trying to get an LED controlled with my Netduino+ PWM and a 2N2222. When I drive the LED with the Netduino 5V it works perfectly. I can dim and bright the LED to my heart's content with pin6 connected to the base. However, when I use an of the shelf 12V power supply rated for 1000mA to drive the LED, the LED lights up dimly but the PWM has no effect on the LED whatsoever. I suspect it is because I don't fully understand the theory behind it so please excuse my ignorance. I also tried a 9V battery pack with the same result as the 12V power supply. Can someone please shed some light (excuse the pun) on what is happening here? Thanks in advance. P.S. - Should note that I had a 1K resistor between PWM and base and a 68 ohm between emitter and ground.

Hi Galibore,

 

I think your problem is the position of the resistors.

 

They should be above the transistor with the LED - somewhere between the collector and the positive supply as per the diagram from CW2.

 

If your description above is correct and the resistors are below the transistor - between the Emitter and the ground, then when the transistor tries to turn ON, the current flowing in the resistors will raise the voltage at the emitter. This means the voltage at the base must be higher to keep the transistor ON. This is feedback and is often used to limit the gain of a transistor.

 

The Netduino can only drive the voltage on the base to 3.3V. The base of an NPN transistor will be about 0.7V above the emitter when ON, so the emitter is around 2.6V. With 3x68ohms @ 2.6V, the current flowing in the LED will only be about 12mA.

 

Try reorganising the resistors - I think that will do the trick.

 

Hope this helps - Paul




#43295 DFROBOT Buggy

Posted by Paul Newton on 13 January 2013 - 07:27 PM

Hello,

I have made references to my buggy/tank in the past, but never published anything - mostly its because I have not had anything resembling a complete project until now. (I find I need a few hours at a time to get any serious development done.)

 

You tube:

Introducing the buggy.

Negotiating a forest of chair legs, including the rocking chair nemesis.


Netduino:
I am using a Netduino Plus v1 (with all the original non-updated firmware).

Chassis:
The chassis is a DFROBOT ROB0003 buggy which came with four geared DC motors, wheels, battery box, pre-drilled metal work, and all nuts bolts and stand offs. (Current 2013 price is around £35 on ebay). The wheels cope well with carpet and rugs, but the rear wheels can lose traction trying to get a grip when climbing onto a deep pile rug.
The kit of parts came with several extra bits for mounting sensors and I supplemented these with some hand cut and folded aluminium brackets. Once I had a good design for the front of the buggy, I marked out a complete mounting plate in 0.5mm aluminium. This is thin enough that you can cut it with tin snips, but thick enough that it can be drilled without tearing. Everything has been cut and drilled etc., with basic hand tools (no lathes or milling machines required).

Motor control and signal connection:
I have an Ardumoto shield to drive the motors on the buggy. I hav listed this in the Wiki before. This shield can't be connected directly to the Netduino due to the PWM inputs being on the pins that the Netduino does not support as PWM. (I have not checked if the V2 now supports this shield).
I originally designed my "fixit" shield to connect the Netduino to this shield. The fixit shield has now grown with some SFH618-2 opto-isolators and a whole array of three pin connectors for sensors to be attached. In the end, I actually chose not to use it for its original purpose (directly joining incompatible shields), and instead placed the Ardumoto shield inside the chassis. If I had put the Ardumoto shield on top of the fixit shield, it made the assembly too high to fit under the top mounting plate of the buggy. The fixit shield just becoming a ready great way to break out the Netduino pins and add odd bits of extra circuitry.
The Buggy has four motors, whilst the Ardumoto shield only has two channels, so I am driving two motors on each channel.
The opto-isolators on the PWM are not driven ON when the Netduino resets or powers up, so the buggy does not run across the floor during the 2 second boot sequence.

Outputs:
I have added an array of LEDs to help me debug the operation of the buggy. The LEDs tell me what the software has chosen to do: forward (slow/med/fast + veer left/right), back, turn (left/right). The LEDs are driven by a 74HC595 shift register from the SPI pins. I wrote my own SPI driver that allows me to stack multiple SPI devices into a chain, and the hardware of the LED board allows he signals to be routed out to another device in the chain.

Sensors:
I have bought six Sharp distance sensors - three 10cm digital (about £5 each) and three 10 to 80cm analogue (about £11 each). I use one analogue sensor to see what is ahead, and two of them to see what is to either side. Since the buggy is fairly wide, the front sensor will miss obstacles that the wheels can hit. To help prevent these collisions, I tried to use the digital sensors, but they were not very reliable with chair legs. Hence I made my own bumper with two micro switches. This arrangement works fairly well, but there are always obstacles that beat it: glancing objects are not detected, objects that are just above the centre of the wheel, and chair legs that slope towards the buggy.
I now use two of the digital sensors to spot objects when reversing. These are needed less often and so the reliability is less of a problem.

Software:
I found that I could easily write drivers for each of the sensors and actuators, but it was quite hard to come up with a simple program to test them all out together in a convincing buggy program. After some experimentation I have come up with the following which works quite well, but obviously lacks any intelligence.
With the front sensor, I have setup a virtual bumper at about 30cm in front. If an object is too close, the buggy will back off. If an object is further away than the bumper, the buggy will drive forward (the further away the faster it goes) until the object reaches the virtual bumper, then the buggy turns to he left or right.
The side sensors are used to make the buggy veer away from objects to the side - the idea was the buggy would eventually drive parallel to a wall. (Its not quite correct yet).
I made the bumper sensors event driven so that they latch ON as soon as an object strikes them, this prevents obstacles being missed when just polling inputs. The forward speed is filtered so that the buggy builds up speed slowly. This change was made after I found the buggy would ram a chair, move back and then ram it again at full speed.

Current control logic:

if (front wheel bump sensor activated){    // Collision    If (clear behind)    {        reverse away from bump        (if both active then back straight, other wise turn away from obstacle)    }    else    {        turn on spot        (use side ranges to turn away from near objects to left or right)    }}    else if (very close to object ahead){    // Object too close in front    if (clear behind)    {            reverse away from object    }    else    {        turn on spot        (use side ranges to turn away from near objects)    }}else if (near object ahead "virtual bumper"){    // Reached the edge of the room, turn away    turn on spot    (use side ranges to turn away from near objects)}else{    // Keep going ahead, but watch for walls to the side    go forward        use side sensors to gently steer away from side objects        speed dependant on range to object ahead        limit acceleration  }


Future work:
I would like to add a compass module so the buggy can have an objective to move in a particular direction.
I got a surprise Christmas present of a Raspberry Pi, this has a Wifi dongle. I am currently thinking about using it to be the brains of the buggy (generate a map of the room, etc.) and be the link to the outside world. I will probably use the UART or UDP over Ethernet. (UDP will not cost me any GPIOs - I am running out of these!)

 

Conclusions:

If you want to make a buggy - I recommend the DFROBOT ROB0003 chassis. Thanks go to a good friend who donated a spare one!

The analogue Sharp sensors have worked well, but the digital ones were not very good when used for collision detection.
Its really hard to make a bumper that works with all obstacles!

Coming up with intelligent behaviour is tricky.

 

Paul

 

(Please PM me with any spelling/grammar mistakes - post is too big to proof read in one go)

Attached Files




#41402 PWM question (in combination with TIP32)

Posted by Paul Newton on 11 December 2012 - 07:16 PM

You have got a pnp transistor. When you pull the base down to about 0.7 V below your 12V supply, it will turn ON. When the Netduino output is low 0V - it wil be ON. When the Netduino output is high 3.3V - it will still be ON! If you have to use the pnp transistor as shown, you need to use another transistor (npn) and resistors to get the base to swing up above 11.3V. This will also invert the logic, low - off, high - on. Hope this explains it - Paul EDIT added picture. When NPN is OFF, "pull up" reistor hold the PNP base near to 12V, thus turning it OFF. When NPN is ON, it pulls the base down below 11.3V, turning the PNP ON.

Attached Files




#41253 Pulse Sensor

Posted by Paul Newton on 09 December 2012 - 09:13 AM

Hi Curt, I have not used this myself. I have had a quick look at the linked page. There is lots of useful information there for setting up on an Arduino, but I think this could be quite a hard project to set up and get running on the Netduino. Things to consider: The sensor is an analogue device. If you have any problems it will be very hard to know what it is doing without access to an oscilloscope to see the signal the Netduino is trying to capture. The example Arduino code in the link uses an Interrupt Service Routine (ISR) to read the sensor at a regular rate (every 2ms). I think it is fairly important that the sampling is regular because the sampled data is then processed to identify specific parts of the wave form. I don't think the .Net framework will be able to give you this regularity - so it may not be possible to process the data correctly. (You might get around this using an external ADC with a sampling clock, but there may be issues setting that up too - e.g. buffering the sample data until the Netduino has time to read it.) You might consider using a voltage comparator (or op-amp) to turn the analogue voltage to a square wave. This would allow you to add an LED to see the input changing, and if you also used the signal as an input to a digital Netduino pin, you could try using events to count the pulses etc. and get less complex code working before trying to use an ADC. Sorry if I've been a bit negative, you can probably make a good job of it with enough time and tools - Paul




  1. Netduino Forums
  2. → Viewing Profile: Likes: Paul Newton
  3. Privacy Policy
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.