Arduino: Eh, just grab some pliers and bend the pins

The Something Awful Forums > Discussion > Hobbies, Crafts, & Houses > Arduino: Eh, just grab some pliers and bend the pins

«‹›4 »

Bad Munki: Nov 4, 2008; We're all mad here.

It bears pointing out one other potential bonus for using switch statements that if() statements don't do as well, and many people forget: you don't have to use a break after each switch case. If you don't, it'll keep executing the other options until the switch is over or a break is hit. For example:

code:

int j = 0;
switch(n) {
  case 4:
    j++;
  case 3:
    j++;
  case 2:
    j++;
  case 1:
    j++;
}

Now, that's a pretty retarded way to say j=n, but that's usually the case with over-simplified examples. Using it creatively is up to the reader. And you're still only making one comparison here, instead of doing the same structure with a series of if() blocks.

Bad Munki fucked around with this message at 19:21 on Nov 26, 2012

# ¿ Nov 26, 2012 19:13

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 02:03

Bad Munki: Nov 4, 2008; We're all mad here.

Delta-Wye posted:

Hey buddy, my example had fall through

Sure, but I wanted it to be obvious what the potential really is there, instead of just an alternative for "if(a || b)".

# ¿ Nov 26, 2012 20:31

Bad Munki: Nov 4, 2008; We're all mad here.

makomk posted:

Otherwise it's very easy not to notice that there isn't a break - especially if only one or two cases from a complex switch statement don't have them - and even if you do, will you be able to remember whether it was intentional a few months down the line if you come back to the project? Trust me, Future-You will thank you for it.

Be sure to

code:

#define case break;case

for maximum something.

_{(I have no idea if that would actually "work", might depend on the compiler. Mine didn't complain about the #define itself, anyhow.)} :v:

Bad Munki fucked around with this message at 00:41 on Nov 28, 2012

# ¿ Nov 28, 2012 00:37

Bad Munki: Nov 4, 2008; We're all mad here.

Uno, hands down. Probably 95% of the guides and tutorials out there will be based on the Uno. And if you do actually get to the point where you run out of I/O pins, well, at that point it's probably high time you look into how to mux/demux I/O!

# ¿ Jan 31, 2013 01:22

Bad Munki: Nov 4, 2008; We're all mad here.

Well, say you wanted to submit a project to hackaday, and you had 50 LEDs...

# ¿ Jan 31, 2013 01:29

Bad Munki: Nov 4, 2008; We're all mad here.

Capntastic posted:

Yeah but you can just multiplex the Hell out of 'em.

No no, you see, it's for hackaday.

The only remotely plausible actual reason I can come up with is maybe if you were doing some software serial communication and you literally had a ton of external devices going with continuous data streams? But even then, the frequency you can fiddle the outputs and control a mux/demux would be fast enough to reduce it back down to just a couple pins with at least a moderate baud rate. I mean, it's not like you can set two pins faster than you can set one pin twice, since the operation is, I believe, blocking. On the other hand, setting up such a scheme in software would be more of a hassle than just having each serial comm use its own pins.

Isn't the mega also sporting a beefier processor? In which case, that might have been the original impetus behind the mega, and during the development process they said, "Well, we have all these extra pins on the processor, might as well make them available on the board," and thus a surfboard was born.

# ¿ Jan 31, 2013 01:45

Bad Munki: Nov 4, 2008; We're all mad here.

You can buy them on Amazon for $25, prime-eligible if you have it (and if you don't, you can sign up for a free trial month of prime, which means free 2-day air, or $4 per item for next day.)

# ¿ Feb 10, 2013 02:07

Bad Munki: Nov 4, 2008; We're all mad here.

huhu posted:

Decided what better way to spent Saturday night then to get out the Arduino. Made a dimmer that goes through the full range of the RGB colors. Was rather confusing to setup because I used PWM pins as grounds so all the values were inverted so that 0 was high and 255 was low. Any suggestions for another way to do this?

Use the pwm pins to control transistors. Or if you're only driving a couple LEDs, put the pwm pin on the LEDs anode...depends on if your rgb led is common-anode or common-cathode, of course...I can never remember which is more common.

huhu posted:

View My Video

And if you want to smooth the brightness "spikes" where you have two of the internal LEDs on simultaneously, build your color vector in HSV space (just give it max S and V with the H being the only variable, directly controlled by your knob) and then convert to RGB, makes for really nice smooth transitions around the color wheel.

Bad Munki fucked around with this message at 17:37 on Feb 10, 2013

# ¿ Feb 10, 2013 07:05

Bad Munki: Nov 4, 2008; We're all mad here.

Now is the perfect time to do a little reading on multiplexing.

For instance, your float sensors could easily share a pin. Also, they don't actually need two IO pins, they just need a voltage source and a single IO pin (which can still be shared between them.) Without actually reading all the spec sheets, I'm pretty sure ALL your sensors could share a single IO pin with proper multiplexing.

Bad Munki fucked around with this message at 20:48 on Feb 28, 2013

# ¿ Feb 28, 2013 20:45

Bad Munki: Nov 4, 2008; We're all mad here.

It lets you have multiple signals coming in, and just one coming out, which you select with a few control lines. So say you have 8 float switches. They are all hooked up to +3V at one end, and you want to check each one to see if it's closed. You connect them up to your multiplexer, and connect the output line from there to your one IO pin on your arduino. Since you have eight lines coming into the multiplexer IC, you'll need just three to control which input you let through at any moment, counting them in a binary fashion, so your three control lines will be 000, 001, 010, 011, 100, 101, 110, 111 which maps to input 0, 1, 2, 3, 4, 5, 6, 7 respectively.

Note that that only allows you to check each one at any given instant, but by cycling through the input very quickly, it doesn't matter. You just select input 0, read it, input 1, read it, input 2, read it, etc. Unless your float switches are magically changing states tens of thousands of times a second, it's fine.

In the code on the arduino, it'd just be a matter of one extra line for each time you want to read the switches, which would be a call to a function to select the input on the multiplexer. That is, instead of

code:

for(int i = 0; i < INPUT_COUNT, ++i) {
  status = digitalRead(switches[i]);
  // do some poo poo with that info
}

you'd have

code:

for(int i = 0; i < INPUT_COUNT, ++i) {
  selectSwitch(i);
  status = digitalRead(THE_ONE_MAIN_IO_PIN_FOR_ALL_THE_SWITCHES);
  // do some poo poo with that info
}

with that new function just being something simple like

code:

void selectSwitch(int s) {
  for(int i = 0; i < 3; ++i) {
    digitalWrite(cPins[i], (s>>i)&1); //this just peels off the last bit, or at least that was the intent, but you get the idea
  }
}

cPins is just a 3-element array listing the pins you have your multiplexer control lines hooked up to.

Mind you, that code up there is completely off the top of my head and isn't checked at all for soundness or correctness in functionality or syntax, it's just to give you the gist of what you're going for here. The point here is that instead of your 8 switches needing 8 IO pins, your 8 switches now need 1 IO pin and 3 control pins, for a total of 4.

Bad Munki fucked around with this message at 01:41 on Mar 1, 2013

# ¿ Mar 1, 2013 01:37

Bad Munki: Nov 4, 2008; We're all mad here.

Is this just a problem with when the joystick is untouched and should be dead in the center, or are you actually experiencing issues when moving it around off-center?

For the former, the simplest solution would be to simply have a dead-zone, i.e. consider (x, y) = (0, 0) if abs(x, y) < (10, 10), for instance. Or if you want a circular dead zone instead of a rectangular one, use a threshold on the distance vector from (0, 0) to (x, y) instead.

If the latter, probably the easiest solution would be to have a "mobile" dead zone as above, but use the difference between the current reading and the previous one. That is, consider (x, y) = (oldx, oldy) if abs((x, y) - (oldx, oldy)) < (10, 10). Obviously, you preserve (oldx, oldy) until you detect sufficiently large movement, as opposed to updating it each time whether you discarded the new reading or not. If you updated it each time, then very slow movements of the joystick would get ignored.

Alternately, as above except keep a running average of the last 10 (or 100, or 1000, or whatever) reads, and use the same mobile dead-zone idea.

Bad Munki fucked around with this message at 02:03 on Mar 25, 2013

# ¿ Mar 25, 2013 02:00

Bad Munki: Nov 4, 2008; We're all mad here.

If I'm reading your output right, it's printing x,y,x,y,x,y,x,y,x,y etc, so every other value is for one axis. In which case, that 0 was preceded by 53 and followed by 34, which doesn't seem TOO far off. I mean, you were bring the joystick "down" along that axis. What is the full range of each axis? That is, does it go from 0 at the middle up/down to +/-MAX, or is it 0 on one edge and MAX on the other?

# ¿ Mar 25, 2013 02:56

Bad Munki: Nov 4, 2008; We're all mad here.

Ohhhhhhhhhh, hahaha. I thought you were slowly dragging the joystick across the field. So what's the actual range if you do move it from min to max?

The reason I ask is because that'll help us figure out a "good" size for the dampening zone.

Also, I'm not clear on why the 0 shouldn't be there. What's so offensive about that one value? If you didn't move the joystick at all, they should all be roughly in the same range, so there's more going on here than just one errant value: your joystick is drifting from roughly 500 to 0 by sitting still (which also makes the min/max values important.)

To be clear: you're not seeing bounce or similar as described in the video you linked. You're seeing some massive drift that is likely brought on by any number of other issues. Dealing with that drift is (apparently) what you actually need to do. I say massive because the range of values on analogRead() is [0-1023] and since you claimed you didn't move the joystick at all, a drift of 500 is half your entire range. That is, without touching it, your joystick drifted the equivalent of moving it from the center, all the way to hard against one edge.

With that in mind, I'd want to see a schematic of your circuit to make sure you're not doing something wrong that is causing the voltage coming from the joystick to slowly decrease.

Bad Munki fucked around with this message at 04:05 on Mar 25, 2013

# ¿ Mar 25, 2013 03:42

Bad Munki: Nov 4, 2008; We're all mad here.

evensevenone posted:

What I'm saying is that usually a joystick has two potentiometers, one for each axis. A pot has 3 leads, and one lead is ground, one lead is +5V, and one lead is signal. And the signal will go from 0 to 5 as you go from one side to another.

But you said you connect left to A1 and right to A0. That doesn't make any sense. There should be an X axis that is left/right and a y-axis that is up/down.

Yeah, that had me puzzled as well. There's almost no way one axis has two outputs since they are, by definition, mutually exclusive. Unless, as was suggested, it's digital.

Got a make/model for the stick?

e: Edits bring more info.

If it is digital, yeah, you don't need to be doing analog anything. Also, in that case, you will need to debounce it, but that's not the problem you were seeing thus far, because you were only reading once every half a second or so in your test code up there.

Bad Munki fucked around with this message at 05:59 on Mar 25, 2013

# ¿ Mar 25, 2013 05:56

Bad Munki: Nov 4, 2008; We're all mad here.

huhu posted:

Edit: Time for more (uneducated) questions. Since I'm done coding, I'd like to remove my Arduino Uno from the setup for my game and run it some other way. I was looking at the Mini but it's $10 plus the $15 for the adapter so I can write code from USB to the Mini. I'm guessing this isn't the solution but can I put the code on the Atmega328 chip and then hook up everything to that with the chip plugged directly into a breadboard? I'm assuming this isn't the answer so I turn to SA for help. How should I solve this?

You can absolutely do that, it's the norm: once you're done prototyping, ditch the prototyping board. You can get a bare atmega and flash the bootloader yourself and then dump your code on it, or you can get one from, say, sparkfun, with the bootloader already in place, and you just plug it into the socket on your arduino and dump your program on it. Once you've done that, you're free to pull the atmega out of the socket on the arduino and install it somewhere else. Google around for barebones arduino or something like that to find out the bare minimum of what you need to use it as you expect. It's pretty drat simple.

For that reason, in fact, it's nice to keep a few spare atmegas around and just one actual arduino. Then you can avoid sacrificing an arduino for every project.

# ¿ Mar 27, 2013 02:50

Bad Munki: Nov 4, 2008; We're all mad here.

I'd suggest posting either the entire program, or even better, an entire simplified program that demonstrates the problem. We can't see under what conditions you're calling HeartBeatCommand, for instance, or what kind of setup you have, or really anything else. The functions you chose to share look okay, so the problem is likely elsewhere or due to some interaction between the shared code and the not-shared code.

# ¿ Apr 21, 2013 15:49

Bad Munki: Nov 4, 2008; We're all mad here.

What range of motion are you after? What sort of load?

Is this because you saw that preview for whatever movie it was that has that dude laying on the bed that looks like one of those pin-impression-box things and it's holding him all floating around magic-like? :v:

# ¿ May 7, 2013 00:57

Bad Munki: Nov 4, 2008; We're all mad here.

So some sort of automagic one of these things, then? I just mean in principle, is all.

Or some other surface? Like, that sort of thing across the surface of the sphere would be intensely cool as well, as it could drive itself across most any surface, especially coupled with a little feedback on the pins.

# ¿ May 7, 2013 01:17

Bad Munki: Nov 4, 2008; We're all mad here.

It's going to be harder because you've never programmed before. With that in mind, the first thing you'll want to do is establish a basic understanding of program controls, structures, and flow. For that, just google around for some C tutorials. Here are a few (scroll down to the second section, titled "C Tutorial - C Made Easy"): http://www.cprogramming.com/tutorial.html

For Arduino-specific stuff, the nice folks at Arduino HQ have a good series of tutorials covering all sorts of Arduino-related topics covering everything from simply blinking a single LED to controlling a full-on robot: http://arduino.cc/en/Tutorial/HomePage

If you have the time, it'd probably be a good idea to enroll in a programming class if you can find one. Really any beginner-level class will do, but for your purposes, a class working in C would be optimal. Formal schools are good, but you might find something better tailored to your goals through a less formal group, such as a makerspace. Philadelphia has several, and I'm sure at least one of them has some programming classes once in a while. Just poking at their websites real quick, it looks like Hive76 has a microcontroller workshop coming up, that might be right up your alley. Here's a list of local makerspaces: http://hackerspaces.org/wiki/Philadelphia

Hopefully that's enough to at least get you moving in the right direction.

# ¿ May 28, 2013 01:25

Bad Munki: Nov 4, 2008; We're all mad here.

I was just recommending the class as an alternate form of learning--and specifically a class at a makerspace because it'll likely be tailored for exactly what he's going to be doing. Different people learn different ways, and for some, an interactive class is the best option. For others, a written tutorial is fine. While I agree that for a lot of basic stuff you can sort of bludgeon your way through by mashing up various examples, if you don't know how to program at all, that's REALLY not going to get you very far, and the first time something doesn't luckily work, you'll be completely stuck. Remember, completely new to programming means you don't know about functions, you don't know about logic statements, you don't even know about variables. That is stuff that is the most fundamental part of ANY programming language, and without those basic tools at your disposal, you're going to have a really hard time, if you meet with any success at all. How, pray tell, do you customize someone's code if you don't even know how to read it?

So yeah, with that in mind, you have to start somewhere, and "learning to program" is the first step, be it through a class, a tutorial, or, as you suggested, a book.

# ¿ May 28, 2013 03:24

Bad Munki: Nov 4, 2008; We're all mad here.

What's the easiest route to get my arduino to make an http request to a server on the web somewhere with a little bit of data via url params? I'm looking at xbees and wifi shields and such, but the former seems to be more for xbee-to-xbee communication (for mesh networks) and both seem to be more geared towards a much lower level of communication than I'm after. I literally just the path of least resistance to being able to periodically hit something like http://mysite.com/logger?val=X

I like the xbee more if I can easily make it do what I want because it seems to be a more interesting module in general (and is more readily compatible with my teensy, which isn't required, but a definite plus), but if it's going to be a huge hassle software-wise, I'm less interested.

# ¿ May 29, 2013 20:56

Bad Munki: Nov 4, 2008; We're all mad here.

Yep.

# ¿ May 29, 2013 21:40

Bad Munki: Nov 4, 2008; We're all mad here.

I think that last item--the 802.11b/g xbee-form-factor board--might be just what I'm after. I'll have to look into writing some arduino software against it just to see what'll be involved.

# ¿ May 29, 2013 22:32

Bad Munki: Nov 4, 2008; We're all mad here.

vas0line posted:

I'm building a bigass MIDI controller from scratch. I have a bunch of sketches written and tested, and a bunch of little "blocks" built (PCB soldered to knobs and buttons). The concept is something quite modular, where it would be possible to basically copy and paste functions in. Gonna post a thread when it's finished, just waiting for more loving wire connectors to show up.

I was wondering... A lot of the code uses for loops to cycle through multiplexers and LEDs and poo poo. For my purposes I want a fast codebase.
SO I was wondering. Which would run faster, a for loop or just addressing each thing in its own line or whatever?

This, where each instruction is a separate thing:
code:
void loop() {
	digitalWrite(1, HIGH);
	digitalWrite(2, HIGH);
	digitalWrite(3, HIGH);
	digitalWrite(4, HIGH);
	digitalWrite(5, HIGH);
	digitalWrite(1, LOW);
	digitalWrite(2, LOW);
	digitalWrite(3, LOW);
	digitalWrite(4, LOW);
	digitalWrite(5, LOW);
}
Or a for loop:
code:
void loop() {
	for(int i=0; i<5; i++){
		digitalWrite(i, HIGH);
	}
	for(int i=0; i<5; i++){
		digitalWrite(i, LOW);
	}
}

A third option is that you could #define a shorthand for it that would be both readable, short, and force the technically-guaranteed-to-be-at-least-as-fast-if-not-ever-so-marginally-faster unrolled version, something like

code:

#define spew(a, b, c, d, e) digitalWrite(1, a); digitalWrite(2, b); digitalWrite(3, c); digitalWrite(4, d); digitalWrite(5, e);
...
spew(HIGH, HIGH, LOW, HIGH, LOW);

e: Of course, that's assuming you want different values on each pin. If you want literally the examples you posted, something like the following might be even simpler:

code:

#define spew(a) digitalWrite(1, a); digitalWrite(2, a); digitalWrite(3, a); digitalWrite(4, a); digitalWrite(5, a);
...
spew(HIGH);
spew(LOW);

Bad Munki fucked around with this message at 02:20 on Jun 10, 2013

# ¿ Jun 9, 2013 22:00

Bad Munki: Nov 4, 2008; We're all mad here.

Forget the jumper cables, just get some old cat 5 and strip off the sheath. Yeah, they're not the optimal gauge for a breadboard, but they work fine.

Also, did you have some particular project in mind already? I just ask because you're trying to pinch pennies on the arduino and other components (which is fine, nothing wrong there) but you're buying a display right off the bat, which implies you have something in mind.

If you can find one for a price you like, I'd recommend getting a breadboard with vertical rails along each edge. They're incredibly useful as power rails for whatever you're working on.

I'd recommend getting a small smattering of components. Some 100/200/470/47k/100k resistors would be a really basic set but would probably suit you for a lot of tasks. A similar spread with capacitors, just google up a few projects, see what they use, and get a handful of each. Do NOT buy from radioshack. 5 resistors at the shack will cost you the same as 250 from, say, digikey. Also get some LEDs, maybe some pots and buttons and dipswitches, that all depends on what you might be doing. I've started making a habit of any time I need a part, I buy a bunch of them. Need a resistor I don't have? Order a 100-pack. Costs me a few extra bucks, but more and more I'm finding I already have everything I need.

And yeah, once you upload your code to the board, if you provide external power, it'll run just fine on its own. Power can be from a wall wart, from a 9-volt battery plugged into the appropriate pins, whatever.

# ¿ Jul 25, 2013 20:17

Bad Munki: Nov 4, 2008; We're all mad here.

If you keep the arduino hooked up to a computer via USB, you can send any data you collect to the computer via Serial, and then you can do all sorts of crazy stuff beyond just displaying it on a tiny screen.

# ¿ Jul 25, 2013 21:12

Bad Munki: Nov 4, 2008; We're all mad here.

Yeah, you can have a program on the computer listening/talking to the arduino over that serial port. Case in point: I saw one where a computer was listening to music and doing FFTs and such (much too heavy for an arduino to calculate) and then spitting the results via serial to an arduino, which was in turn using those results to drive a 5 meter ws2801 LED strip with eye candy.

For super easiness, check out the Processing environment. There are libraries readily available that will handle the communication between the two, you just spew/read data as needed and then do amazing pretty things in Processing because Processing is the poo poo for low-overhead (and/or one-off) graphics stuff.

# ¿ Jul 25, 2013 21:59

Bad Munki: Nov 4, 2008; We're all mad here.

With that in mind, I'd probably skip the little screen if your budget is super tight. There are only a handful of projects I've actually wanted one, and I've generally just found other ways (serial connection, that sort of thing.)

# ¿ Jul 26, 2013 02:19

Bad Munki: Nov 4, 2008; We're all mad here.

Okay, yeah, I guess I said FFTs were too much for an arduino, but it was meant more as "too much for an arduino that wants to do a bit of other interesting stuff as well."

# ¿ Jul 26, 2013 18:40

Bad Munki: Nov 4, 2008; We're all mad here.

How old is your son?

# ¿ Jul 31, 2013 18:47

Bad Munki: Nov 4, 2008; We're all mad here.

Just throwing it out there: http://www.amazon.com/gp/product/B0000683A4/ref=oh_details_o02_s00_i00?ie=UTF8&psc=1

PERFECT for that age, and has tons of fun devices (lights, speakers, motors, switches, a helicopter rotor that launches?!) and such that you won't get out of most arduino kits. Is more rugged than a breadboard with components. Skips the whole overly-tedious-and-complex microcontroller stuff you have to fuss with with an arduino.

The arduino might be more fun for you, granted, but for a father/8-year-old-son combo? My money is hands down on that kit there. I got one for a friend and his boys (right at that age) love it (they are also a very technologically-oriented family), and I know a couple other people have recommended that kit (and its brethren) as well. Heck of a lot cheaper than the arduino kit, to boot!

# ¿ Jul 31, 2013 19:16

Bad Munki: Nov 4, 2008; We're all mad here.

Haha! Right on.

As for the kit you linked originally, it's hard to say, I don't see a list of actual contents, although the projects sound interesting enough. From the comments, it SHOULD be a <$100 kit, but it sounds like maybe the kits have gone a bit scarce from the $100 providers, so yay price hike. In any event, the comments are generally pretty positive, so that's good. If you aren't too worried about spending $125 on it, I'd say I guess go for it? You could almost certainly get all the same parts for less than that total price, but then you have to figure out what parts/accessories you need, and how to actually use them. To me, there's value in having someone else do that for you in certain situations (such as when working with an 8 year old.) At the very least, you'll have some fun components and an arduino.

# ¿ Jul 31, 2013 19:28

Bad Munki: Nov 4, 2008; We're all mad here.

Be sure to post a trip report just for informational purposes.

# ¿ Jul 31, 2013 19:52

Bad Munki: Nov 4, 2008; We're all mad here.

I don't think an accelerometer alone would suffice, or would be horribly inaccurate, and not due to a limitation of the arduino. Throw a gyro in the mix and you'll get better. Combine it with some gps and some sensors at the wheels to detect rpm and you'll have onstar.

# ¿ Aug 1, 2013 20:53

Bad Munki: Nov 4, 2008; We're all mad here.

JawnV6 posted:

How does a gyro help? I kinda want to bang this together over the weekend, which puts GPS out of my time window.

Well, an accelerometer doesn't handle rotation at all, and what if you're accelerating up or down a hill? You need to know the angle of the dangle in order to factor in multiple vectors of acceleration: gravity (which suddenly isn't fixed because your accelerometer can change angle on a hill) vs. your car's engine pushing it forward or back, vs. the acceleration to the side (in the vehicle's reference frame) as you go around a corner. There may be others I'm not thinking of.

The gyro(s) provides you with that extra information which lets you do some (relatively) simple math to get MUCH more accurate positioning. The big addition the wii motion plus added was a set of gyros to alleviate the errors created by relying solely on accelerometers.

# ¿ Aug 1, 2013 21:23

Bad Munki: Nov 4, 2008; We're all mad here.

Right, and the way to really do what you seem to want would be a rotary encoder on the wheels.

But assuming that's not an option, you're trying to fake it with an accelerometer, and it's going to be extremely rough (read: probably more wrong than right) in almost every case without additional sensors.

I'm not saying don't give it a shot, but just also expect that the data you get out is going to be pretty whack.

With all that in mind: no, I don't think an arduino will be insufficient for the job. You can build one for like $5, too, so if you want to just give it a shot, your investment will be minimal.

JawnV6 posted:

I'm in a pretty simple problem space. A single dimension's positioning is enough, I'll fix up the rest of it in software. I'm going to try swinging by Radio Shack to see if they've got something, otherwise I'll be getting something overnighted.

Your end result is, yes, but there are multiple vectors of acceleration being applied to that one final resultant vector. And if you don't account for those, it's going to be wrong.

As an example, say you have your one accelerometer aligned with the direction your car travels, front to back. Then you park on a hill. Your accelerometer reads some portion of the gravity vector and shows your car accelerating (albeit slowly) forever. By the time you get up in the morning, your car has slowly crept up to a thousand miles an hour, without going anywhere a tall! That's why you need a gyro, to be able to measure the direction your car is facing and nullify that portion of the gravity vector. Same thing happens when you go around a corner.

Bad Munki fucked around with this message at 21:31 on Aug 1, 2013

# ¿ Aug 1, 2013 21:26

Bad Munki: Nov 4, 2008; We're all mad here.

Like I said, a basic arduino can be built for practically nothing, and I doubt the arduino itself will be the limiting factor here, so the answer to the original question is probably yes, the arduino can do it* and you should go for it.

*With caveats on what "it" is. :haw:

# ¿ Aug 1, 2013 21:43

Bad Munki: Nov 4, 2008; We're all mad here.

I like the tapping into the PWM from the wheels (basically what I said: a rotary encoder on the wheels, just through an already-present mechanism.) But if the goal is to have a black box you can just set somewhere in any car, that won't really work because it requires poking around in the car.

If the goal is a completely atomic black box and it's really just drag activity, it might work well enough. No wheelies, though, that'll dick things over again. But if that is the goal, you know you could just grab the accelerometer data from practically any smartphone and spend five minutes hacking out a little app for it to log runs. There's probably already a million apps out there for free that would do just that and could spit out the data to a csv or something that you could later process. As a proof of concept for "will accelerometers alone work," that might be your actual best bet, assuming you have a smartphone and aren't some sort of luddite. :v:

Bad Munki fucked around with this message at 23:01 on Aug 1, 2013

# ¿ Aug 1, 2013 22:58

Bad Munki: Nov 4, 2008; We're all mad here.

Thanks, that's what I was trying to get at but your link was way more thought out and explicit.

# ¿ Aug 2, 2013 00:10

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 02:03

Bad Munki: Nov 4, 2008; We're all mad here.

You can get warm-colored white LEDs same as you can get cool-colored incandescent bulbs.

Alternately, adjust the color with a gel. OR, get RGB LEDs and pick your color exactly.

# ¿ Aug 12, 2013 03:58

The Something Awful Forums > Discussion > Hobbies, Crafts, & Houses > Arduino: Eh, just grab some pliers and bend the pins

«‹›4 »