Showing posts with label arduino. Show all posts
Showing posts with label arduino. Show all posts
Wednesday, July 8, 2009
Arduino GPS guidance
I've done a little bit of digging on GPS guidance for the Arduino, my main concern being accuracy of the unit. I've got several projects backed up in my head that involve GPS to some extent, the main project being the Lawnmowbot. But it seems that these projects are in jeopardy as I've found out that the accuracy of the GPS unit ( http://www.robotshop.us/adafruit-gps-logger-shield-kit-arduino-1.html ) is 5 to 10 meters - that's almost 33 feet! I can't mow a lawn leaving a 10 meter buffer ring around obstacles, infact for my yard that may only be one stripe down the center. So unless we can figure out some fancy workaround, the Lawnmowbot is going to have to be shelved. One idea I had is to mount two or three GPS units onto the mowbot. They'll be fixed (and known) relative to eachother, so perhaps we can come up with a method to trim down the error based on their readings and their known distances from eachother. I dunno, I'll probably have to buy one and tinker with it for a while. Worst case, I move on to the next GPS project - I'm thinking a UAV based on a R/C helicopter; 10 meters error shouldn't be detrimental for something like that :)
Monday, July 6, 2009
Arduino + Fridge + Beer = Happiness
Now this is a project worth working on =P link
this is the code from the project. there is likely some cleanup that can be done, or expansion.
this is the code from the project. there is likely some cleanup that can be done, or expansion.
/*
Purpose: Temperature Regulator for a Kegerator with LCD display.
Using a LM35 and Arduino to check temperature and display current temp to an LCD.
Also the Arduino will turn a Solid State Relay on/off within a defined temp range
-LM35 connected to 5V, Grd, Analog Pin 0
-Serial LCD connected to 5V, Grd, Digital Pin 1 (tx pin)
-SS Relay connected to Grd, Digital Pin 12
-Back Light Button connected to Digital Pin 3, Grd, 5V via 10K resistor (pin pulled HIGH in open state).
Many thanks to Brutus@ brutusweb.com and Mikal @ the Arduino forums for all the help and inspiration!
*/
#define ledPin 13 // LED connected to digital pin 13
#define lm35 0 // LM35 on Analog 0
#define blightPin 3 // Momentary switch for back light to digital pin 3
#define relayPin 7 // Relay connected to digital pin 7
unsigned long last_temperature_check_time = 0;
unsigned long last_lcd_turn_on_time = 0;
void sendlcd(byte command) //Quick function to send LCD commands.
{
Serial.print(command, BYTE);
}
void setup() // run once, when the sketch starts
{
analogReference(INTERNAL); //using internal voltage reference ~1.1v
pinMode(ledPin, OUTPUT); // sets the digital pin as output
pinMode(lm35, INPUT); // sets the analog pin as input
pinMode(blightPin, INPUT); // sets the digital pin as input
pinMode(relayPin, OUTPUT); // sets the digital pin as output
digitalWrite(ledPin, HIGH);
delay(1000);
Serial.begin(9600);
delay(1000); //Let Ports Stabilize
sendlcd(27); //Reset Command For LCD
sendlcd(122);
delay(500); //Full Reset takes a bit
sendlcd(254); //Clear and Go Home on LCD
sendlcd(1);
digitalWrite(ledPin, LOW); //turn off LED
delay(250);
}
//new loop with millis... sweet
void loop() // run till the end of days or the beer runs out...
{
unsigned long time = millis();
if (time - last_temperature_check_time > 20000) //has it been 20 seconds?
{ last_temperature_check_time = time;
digitalWrite(ledPin,HIGH); //turn on LED for running routine status
//Check Temperature routine
long temp;
long temp1;
long temp2;
long temp_x;
int lm35_val=0;
//delay(500); //Delay to allow stabilized analog read.. not needed?
lm35_val=analogRead(lm35); //read value of center leg of LM35
temp = lm35_val; //output voltage of LM35, 10mV = 1 Degree Celcius
temp1=temp/10; //creates true Celcius reading
temp2=temp%10; //modulus operation to calculate remainder for higher resolution reading
if (temp2 >= 5){
temp_x++;
}
//Send temperature to LCD routine
sendlcd(254); //Clear LCD Screen
sendlcd(1);
Serial.println("Current Temp"); //Print "Current Temp" message
Serial.print(temp1); //Print CelsuisTemperature
Serial.print("."); //Print decimal place
Serial.print(temp2); //Print "Tenths" place
sendlcd(223); //Print degree charater
Serial.print("C"); //Print "C" for Celsuis
digitalWrite(ledPin,LOW); //Turn off LED
//Turn Relay on/off routine
if ((temp1) > 7 ) //check temp is above x degrees
{
digitalWrite (relayPin, HIGH); //if temp is above x degrees turn pin "ON"
}
else if ((temp1) < last_lcd_turn_on_time =" time;"> 10000) // has it been 10 seconds?
{
sendlcd(27); //Turn back light off
sendlcd(42);
sendlcd(0);
}
}
Tuesday, June 30, 2009
More learning on the Arduino...
So I was able to control a servomotor with a potentiometer this past weekend. That was pretty cool, it was pretty much 1:1, half turn on the pot was about a half turn on the servo. I was using Analog out to control the motor, most of the tutorials I've found use PWM on a digital pin. Seems my way is easier (but I'm sure there's a reason for the PWM on digital that I have yet to discover).
Then I got the wild hair to hack an old mouse. Didn't work too well, but nothing detrimental. I cut off the PS/2 plug and stripped the wires: red, green, blue and white - notice anything missing? That's right, the black. But that's not the worst of it, the red wasn't even the power in; the blue was. green happened to be ground, red and white were send and receive. It took 5V @ 20 mA - just about the upper safe threshold for the Arduino. I wrote a program that read the red and white and sent back to the computer what it was reading to print on screen. I know something was going on because I initialized the variables to 0 but all I got on screen was:
mouseVar1 = 1
mouseVar2 = 1
mouseVar1 = 1
mouseVar2 = 1...
so it was reading something, but nothing discernible. I read online that the receive line was supposed to be a clock signal, so I'm guessing the mouse was having a hissy fit because it wasn't getting a clock in. I probably should have read a little more on the PS/2 mouse - somehow you're supposed to get an X, a Y, and 3 mouse clicks from just one line.
Next on the list, I'm going to have to buy a few MOSFETs and start learning about controlling high loads. Though here is a gripe I'm having with all of these tutorials, it's a trap I'm sure I'd fall into if I were writing them as well. It seems to me that the people writing these tutorials know the subject so well they're taking for granted that their audience knows certain things. For example, yesterday I searched between 10 and 15 tutorials for controlling DC motors with the Arduino, no two were alike when it came to the additional circuitry required to control the higher loads. That's fine, it shows the flexibility and different options. But what's not fine is not a single one explained why they chose what they did. Some used MOSFETs, others used H-bridges, some used 2 H-bridges, others used commercial motor control chips, and there were more that used off the shelf motor shields. Another example is the resistors, all the tutorials say "use xx Ohm resistor" and I'm left thinking, "Ok, no problem but... why that value?"
I'm mechanical. If I can't see it, I have a hard time figuring out how it works. A little explanation would go a long way to improving some of these tutorials.
[EDIT] Ok, so I'm learning now :P
It seems that the MOSFET is used for simple one direction high load on/off switching.
The H-bridge is for bi-direction, varying loading, and multiple high loads, and seems to be basically an array of MOSFETs.
here's a good academic link:
http://itp.nyu.edu/physcomp/Labs/DCMotorControl
Then I got the wild hair to hack an old mouse. Didn't work too well, but nothing detrimental. I cut off the PS/2 plug and stripped the wires: red, green, blue and white - notice anything missing? That's right, the black. But that's not the worst of it, the red wasn't even the power in; the blue was. green happened to be ground, red and white were send and receive. It took 5V @ 20 mA - just about the upper safe threshold for the Arduino. I wrote a program that read the red and white and sent back to the computer what it was reading to print on screen. I know something was going on because I initialized the variables to 0 but all I got on screen was:
mouseVar1 = 1
mouseVar2 = 1
mouseVar1 = 1
mouseVar2 = 1...
so it was reading something, but nothing discernible. I read online that the receive line was supposed to be a clock signal, so I'm guessing the mouse was having a hissy fit because it wasn't getting a clock in. I probably should have read a little more on the PS/2 mouse - somehow you're supposed to get an X, a Y, and 3 mouse clicks from just one line.
Next on the list, I'm going to have to buy a few MOSFETs and start learning about controlling high loads. Though here is a gripe I'm having with all of these tutorials, it's a trap I'm sure I'd fall into if I were writing them as well. It seems to me that the people writing these tutorials know the subject so well they're taking for granted that their audience knows certain things. For example, yesterday I searched between 10 and 15 tutorials for controlling DC motors with the Arduino, no two were alike when it came to the additional circuitry required to control the higher loads. That's fine, it shows the flexibility and different options. But what's not fine is not a single one explained why they chose what they did. Some used MOSFETs, others used H-bridges, some used 2 H-bridges, others used commercial motor control chips, and there were more that used off the shelf motor shields. Another example is the resistors, all the tutorials say "use xx Ohm resistor" and I'm left thinking, "Ok, no problem but... why that value?"
I'm mechanical. If I can't see it, I have a hard time figuring out how it works. A little explanation would go a long way to improving some of these tutorials.
[EDIT] Ok, so I'm learning now :P
It seems that the MOSFET is used for simple one direction high load on/off switching.
The H-bridge is for bi-direction, varying loading, and multiple high loads, and seems to be basically an array of MOSFETs.
here's a good academic link:
http://itp.nyu.edu/physcomp/Labs/DCMotorControl
Wednesday, June 24, 2009
"My" first Arduino program
Ray invited me to post on his blog to share in learning experiences and to collaborate on different projects. We both seem to be interested in learning the Arduino at the moment, so here's a bit on that, "my" first Arduino program. Not too interesting to many, but to anyone learning microcontrollers (specifically the Arduino) there might be a lesson or two to be gleaned.
I'll admit that it's not 100% mine, infact it's nearly all not mine (thus the quotes around "my"), BUT it didn't come verbatim from a tutorial (I hacked a couple tutorials to come up with it, mainly to force me not to just follow the bouncing tutorial-dot). It's a script that has chasing LEDs (Knight Rider style), and the speed which the LEDs chase is controlled directly with a potatometer (less resistance = faster chase. From 0 millisec up to 1023 millisec, just over 1 full sec in between flashes for max resistance).
The code is posted below. I would have posted pictures but my camera seems to have a crappy USB port, and won't upload pics. A moving picture would be better, but to my knowledge man has yet to invent moving pictures (or "movies" as I would like to call them).
The Schematic shown here is, if nothing else, pretty ugly. The jagged scribbles between the Arduino and the LEDs are resistors (I used 220 Ohm, for no other reason than that's about what all the tutorials use for LEDs - no idea why that specific value though). There's also an error in it, the digital pins 1-5 should be 2-6.
The first thing I realized was that pin 14 is also analog pin 0. They're one in the same, the only difference is when using it as an analog pin with "analogWrite" (or read) it's pin 0, when using it as a digital pin with "digitalWrite" (or read) it's pin 14. The second interesting thing I learned was kind of the opposite of PWM control, though it was inadvertent. I accidentially hooked up the potatometer's ground to the LED ground. When I ran the program, the potatometer controlled the brightness of the LED's rather than their speed. I was using an analog signal to control the digital outputs (in PWM, you use pulsed digital to control analog). Another interesting thing was that the Arduino was still reading the analog 0 pin (which was hooked up to nothing) so it read some random value, which just happened to give me about a half-second delay. Luckily I saw that I was hooked up incorrectly and rewired. The program ran exactly as intended. Turning the pot slowed or sped the chasing lights accordingly.
This excercise also drove home the operation of the "for" function. When the lights are chasing quickly, you don't notice, but when they're chasing slowly and you turn the pot, the way this program is structured, the lights will complete their chase before reading the new pot value to speed things up.
I was also able to notice how the "delay(x)" function delays everything - could be bad to use in certian situations when you need an immediate change or read, etc... if the sketch is in the middle of a "delay" it doesn't seem to respond to anything until it's good and ready.
Thanks for reading, hope I didn't bore you too much and maybe you learned from some of my errors.
Here's the code:
I'll admit that it's not 100% mine, infact it's nearly all not mine (thus the quotes around "my"), BUT it didn't come verbatim from a tutorial (I hacked a couple tutorials to come up with it, mainly to force me not to just follow the bouncing tutorial-dot). It's a script that has chasing LEDs (Knight Rider style), and the speed which the LEDs chase is controlled directly with a potatometer (less resistance = faster chase. From 0 millisec up to 1023 millisec, just over 1 full sec in between flashes for max resistance).
The code is posted below. I would have posted pictures but my camera seems to have a crappy USB port, and won't upload pics. A moving picture would be better, but to my knowledge man has yet to invent moving pictures (or "movies" as I would like to call them).
The Schematic shown here is, if nothing else, pretty ugly. The jagged scribbles between the Arduino and the LEDs are resistors (I used 220 Ohm, for no other reason than that's about what all the tutorials use for LEDs - no idea why that specific value though). There's also an error in it, the digital pins 1-5 should be 2-6.
The first thing I realized was that pin 14 is also analog pin 0. They're one in the same, the only difference is when using it as an analog pin with "analogWrite" (or read) it's pin 0, when using it as a digital pin with "digitalWrite" (or read) it's pin 14. The second interesting thing I learned was kind of the opposite of PWM control, though it was inadvertent. I accidentially hooked up the potatometer's ground to the LED ground. When I ran the program, the potatometer controlled the brightness of the LED's rather than their speed. I was using an analog signal to control the digital outputs (in PWM, you use pulsed digital to control analog). Another interesting thing was that the Arduino was still reading the analog 0 pin (which was hooked up to nothing) so it read some random value, which just happened to give me about a half-second delay. Luckily I saw that I was hooked up incorrectly and rewired. The program ran exactly as intended. Turning the pot slowed or sped the chasing lights accordingly.
This excercise also drove home the operation of the "for" function. When the lights are chasing quickly, you don't notice, but when they're chasing slowly and you turn the pot, the way this program is structured, the lights will complete their chase before reading the new pot value to speed things up.
I was also able to notice how the "delay(x)" function delays everything - could be bad to use in certian situations when you need an immediate change or read, etc... if the sketch is in the middle of a "delay" it doesn't seem to respond to anything until it's good and ready.
Thanks for reading, hope I didn't bore you too much and maybe you learned from some of my errors.
Here's the code:
/* Variable Chasing LEDs
This adjusts the rate at which a chasing LED array operates
Circut: Potatometer is attached to analog input 0 (digital pin 14), 5 LEDs are attached to digital outputs 2 through 6 (to ground through 220 Ohm resistors).
*/
int sensorPin = 0; //initalize which pin is potentometer input
int ledPin[] = {2,3,4,5,6}; // initalize LED pin outputs
int numleds = 5; // number of LED outputs in circut
int potVal = 0; // potentometer's value (initalized @ zero)
void setup(){
//loop to initalize LED pins as outputs:
for(i=0; i
pinMode(ledPin[i], OUTPUT);}
}
void loop(){
potVal = analogRead(sensorPin); //read potentometer value
// forward chasing, delayed according to value of potentometer:
for(int i=0; i
digitalWrite(ledPin[i], HIGH);
delay(potVal);
digitalWrite(ledPin[i], LOW);
}
// now back chasing:
for(int i=numleds-1; i>=0; i--){
digitalWrite(ledPin[i], HIGH);
delay(potVal);
digitalWrite(ledPin[i], LOW);
}
}
Monday, June 22, 2009
Arduino and Contributing Author
The main intention of the blog is for it to be as much a way to share research progress as it is a way to keep in touch with friends and family. As such I want to share this space with my good friend Ben who is a fellow Casual Engineer (and who it happens my son is named after). I look forward to future posts from him =)
Ok, now an update on our Arduino progress. Ben got his hands on a Duemilanove this past week and got to monkeying with the tutorials. I have to still order mine but am reading as much as I can beforehand, not to mention daydreaming about all the projects =) MMmmmmm kegerator outfitted with sensors and digital display. It could send a tweet when the keg is running low, or maybe send a preformatted email to the local distributor to order a new one. Excellent!! (insert maniacle laugh)
Here are some of my favorite links so far:
Arduino's main site
Hacknmod
Ladyada
Sheepdog
So far I'm really liking how simple the basic software structure is.
void setup(){
setup stuff;
}
void loop(){
do stuff;
}
pretty cool. more to come later.
oh and a bit of coolness. uav with arduino =P
Ok, now an update on our Arduino progress. Ben got his hands on a Duemilanove this past week and got to monkeying with the tutorials. I have to still order mine but am reading as much as I can beforehand, not to mention daydreaming about all the projects =) MMmmmmm kegerator outfitted with sensors and digital display. It could send a tweet when the keg is running low, or maybe send a preformatted email to the local distributor to order a new one. Excellent!! (insert maniacle laugh)
Here are some of my favorite links so far:
Arduino's main site
Hacknmod
Ladyada
Sheepdog
So far I'm really liking how simple the basic software structure is.
void setup(){
setup stuff;
}
void loop(){
do stuff;
}
pretty cool. more to come later.
oh and a bit of coolness. uav with arduino =P
Tuesday, June 16, 2009
Python, Arduino, and CUDA
It seems uncommon anymore to get really pumped about something. And by pumped, i mean real ultimate power pumped. It just so happens that a few things have recently got me that pumped.
1. The birth of my son. No question there and pretty self-explanatory so we'll move onto the others.
2. Python programming language. Holy heck is this a rocking language.
3. Arduino prototyping platform. Once again, rocking.
4. nVidia CUDA library. Using your video card as a math coprocessor? Awesome.
I've been programming for a little while now, mostly Matlab and Perl. Some C/C++ from classes but nothing production. It's only been recent that I've discovered Python, and quite frankly I wish I'd discovered it earlier. I'm enjoying how straightforward the syntax is and how much you can do with little coding. It's very programmer friendly. I intend to write much more about Python, especially since there is now a Python interface to nVidia's CUDA library.
The Arduino is essentially the face of physical computing. Generally speaking, it isn't a trivial thing to get your computer to interface with the real world and act upon it. There's all sorts of kits and what have you for the crummy basic stamp and related trash, but they were always extremely limiting and rather proprietary. In fact I always found those to be rather discouraging.
The Arduino, however, is open source, powerful, and very flexible. There are tons of projects on instructables involving the Arduino. There's tons of info out there where all sorts of people have fiddled with it and made really cool things. Heck here's one that has your plants twitter you when they need watering. Freaking cool. The biggest thing about what I find on instructables is how inspiring the projects are. Everyone swears by how easy the Arduino is to program. It's time to start fiddling.
And then there's nVidia's CUDA library. It essentially allows you to use your video card for matrix math operations. The one I have here at work was able to run a n-body simulation with 27,000 objects at 360 GFlops. Trust me, that's freaking insane. It also did an eigenvector decomposition of a 2048 x 2048 randomly generated matrix in 4.8ms. So yeah, if it's matrix math you need done, especially on a large matrix or system of equations, the CUDA library lets you have a supercomputer on your desktop.
Anyways I'll be writing more about these later. This is just the starting point.
1. The birth of my son. No question there and pretty self-explanatory so we'll move onto the others.
2. Python programming language. Holy heck is this a rocking language.
3. Arduino prototyping platform. Once again, rocking.
4. nVidia CUDA library. Using your video card as a math coprocessor? Awesome.
I've been programming for a little while now, mostly Matlab and Perl. Some C/C++ from classes but nothing production. It's only been recent that I've discovered Python, and quite frankly I wish I'd discovered it earlier. I'm enjoying how straightforward the syntax is and how much you can do with little coding. It's very programmer friendly. I intend to write much more about Python, especially since there is now a Python interface to nVidia's CUDA library.
The Arduino is essentially the face of physical computing. Generally speaking, it isn't a trivial thing to get your computer to interface with the real world and act upon it. There's all sorts of kits and what have you for the crummy basic stamp and related trash, but they were always extremely limiting and rather proprietary. In fact I always found those to be rather discouraging.
The Arduino, however, is open source, powerful, and very flexible. There are tons of projects on instructables involving the Arduino. There's tons of info out there where all sorts of people have fiddled with it and made really cool things. Heck here's one that has your plants twitter you when they need watering. Freaking cool. The biggest thing about what I find on instructables is how inspiring the projects are. Everyone swears by how easy the Arduino is to program. It's time to start fiddling.
And then there's nVidia's CUDA library. It essentially allows you to use your video card for matrix math operations. The one I have here at work was able to run a n-body simulation with 27,000 objects at 360 GFlops. Trust me, that's freaking insane. It also did an eigenvector decomposition of a 2048 x 2048 randomly generated matrix in 4.8ms. So yeah, if it's matrix math you need done, especially on a large matrix or system of equations, the CUDA library lets you have a supercomputer on your desktop.
Anyways I'll be writing more about these later. This is just the starting point.
Subscribe to:
Posts (Atom)