Show Posts
Pages: [1] 2
1  Forum 2005-2010 (read only) / Interfacing / Re: Arduino Mega + Ethernet Shield + OSC on: June 18, 2010, 12:28:25 am
After much toiling with middleman apps, I realized this is by far the best approach to handle comms from the Arduino to well, basically anything else... but especially the almighty GlovePIE... which can read practically every input protocol ever invented, then emulate even more devices and protocols... but won't read a serial port  :-X

I wonder also if it something like a wi-fi shield exists... the awesomeness would be hugely increased  smiley-grin

Anyways, from what I've been reading tonight, it seems the Ethernet library can handle UDP, which is pretty much the only requirement for OSC... but I haven't seen an implemented OSC library yet to use with it... My guess is that that part would need to be written yet...

I find it odd that people aren't showing much interest in bypassing the middleman and working on getting the Arduino to speak OSC by itself... that would make working with it a whole lot easier, since there would be no need for intermediary apps to confuse you (even more) when it doesn't work  :smiley


If i can get an ethernet shield, I might just try this... if it works... oh the awesomeness!!

Cheers
2  Forum 2005-2010 (read only) / Interfacing / Re: What pins are serial? on: June 18, 2010, 12:40:03 am
pins 0 and 1 are basically echoing the USB serial stream, so anything sent or read by Serial.read() and Serial.write() will also work with these pins.

I used them yesterday to connect a BlueSMiRF module to my Duemilanove... these modules are made to connect to the 6 pin headers on the Pros and Lillypads, but the Duemilanoves have USB jacks instead of headers, so I used the 0 and 1 pins to connect the module through an overly complicated protoboard kludge, which looks horrible and beautiful at the same time  ;D

Cheers
3  Forum 2005-2010 (read only) / Interfacing / Re: Large LED matrix? on: September 02, 2010, 01:50:36 pm
Quote
It would be more like $2,160. Very expensive.

Yes, it's a big and expensive project... Thankfully I won't be the one paying for it smiley-wink

I did the math, and everything rounds out to about 9 grand... quite a handful of cash, but this is supposed to be a commercial project, so this is actually pretty cheap, compared to what a full-blown LED screen normally costs, which is in the 6 figure range...

Anyways, my plan doesn't involve multiplexing... the idea is to split the matrix into manageable 20x20 modules, each with it's own Arduino Mega as a controller, and a master controller to feed data into them (or more than one, if a single Mega can't handle the data flow)...

So in the end we're looking at 35 Arduino Mega controllers and a 36th as the Master...  ;D

Each arduino will have it's own power supply, and there will be a 12v PSU for each module, so there shouldn't be any problems with astronomical current loads and all that...

Anyways, in the end the idea is starting to sound somewhat ludicrous with all these Arduinos and whatnot... So we're now looking to other options... namely a dedicated screen controller to drive all those LEDs... I mean, if a HDTV can do it with over 2 megapixels, and refresh 60 times a second, there should be some controller out there that can do it for a 120x90 pixel screen

I'm really no expert in any of this, so I don't know much about what can be done and what can't... I'm making this up as I go along...  smiley-wink

Thanks for all the help so far  smiley-grin

Cheers
4  Forum 2005-2010 (read only) / Interfacing / Re: Large LED matrix? on: September 01, 2010, 10:35:19 am
Hmm you guys bring up interesting points... refresh rate is something that hadn't occurred to me until now... not to mention memory restrictions...

Anyways, I'm not worried about current... we would probably use transistor array ICs, so the LEDs would have their own feed...

So, what occurred to me would be to split the matrix into several smaller, say 20x20 matrices, and each be controlled by an individual Arduino... A Master Arduino would be feeding serial data into each matrix controller from it's own data stream, this way they can team up to handle 'byte-sized' tasks  smiley-wink

This would probably require a good deal of Arduinos... but it's still a lot cheaper than a full-size LED screen.

Thanks for the quick replies!! keep 'em coming!  smiley

Cheers
5  Forum 2005-2010 (read only) / Interfacing / Large LED matrix? on: August 31, 2010, 05:22:49 pm
Hello,

I'm trying to figure out if an Arduino could drive a large LED matrix... the matrix will be around 120x90, which means about 10800 LEDs.

I'm almost sure the regular Arduinos don't have enough pins for that, but what about the Mega? would it be possible to hook up that large a matrix into it's 54 pins?

We are still unsure if the LEDs will be single color or RGB... that of course would depend on pricing and how much more complex the matrix would get...

Anyways, if there are not enough pins on the Mega, what about hooking up more than one Mega via serial?

Any thoughts?

Cheers
6  Forum 2005-2010 (read only) / Interfacing / Re: Gyro vs Accelerometer on: June 30, 2010, 11:19:10 am
Quote
Gravity conventionally acts in the z axis.

That depends on your coordinate system... 3D Studio Max, for instance, uses Z as the up-axis and Y as the depth-axis. On the other hand, DirectX uses the Y-up convention (with Z as depth)

So, to avoid confusion, it's best to refer to them as up-axis, forward-axis, and names like that... (X axis is fine since it's always lateral)

Cheers
7  Forum 2005-2010 (read only) / Interfacing / Re: Gyro vs Accelerometer on: June 29, 2010, 02:38:27 pm
Hi again,

Glad I could help smiley

Quote
Am I correct in assuming that the 5 DOF IMU (accelerometer and gyroscope) is mounted horizontally to measure acceleration along all 3 axis and rotation around the X and Z axis?

Bearing that in mind, what purpose does the Dual Axis Gyroscope serve? Even mounted vertically, surely it would still measure rotations around the X and Z axis?

The IMU is one type of sensor that kind of falls out of the absolute/relative labels, because it is both...

Basically it works by, after being calibrated to a known absolute point and orientation, calculating it's current absolute displacement based on relative data...

Did that maky any sense? let me try and clarify it... basically it knows where it is because it knows where's it's been... It's like saying 'I started out at point (0,0), but then I moved 30 in X then 50 in Y, so I must be now in point(30,50) and so on and so on...

Commercial aircraft like the Boeing 747 use this system for location information... the trouble is that it has to be calibrated every once in a while with known positional information, since with this system desynchronizaiton is pretty much inevitable...

But anyways... to answer your question... you're probably right in assuming the 5DOF IMU is sensing all 3 translations and probably pitch and yaw rotations too... the 2 axis gyro is really one axis redundant, but maybe the builder liked to keep his option.

As for your next question, I assume that by Y axis you mean the up-axis (there is more than one axis convention out there)... Also I imagine you mean measuring absolute Y rotation...

That can be done with a magnetometer (which just a fancy word for a multi-axis compass) or a good gyro.

Anyways, a 3 axis magnetometer should be good enough for your roll, pitch and compass heading needs...

For absolute positioning, which given your project is an absolute (no pun intended) necessity, I'd go with an IMU, since it's a self-contained solution... just bear in mind the need for frequent calibration, lest your copter ram into your TV or something  :-X

I'm just another n00b when it come to electronic components, so I'm afraid that's all the help I can give about that... I'm just getting started with the arduino myself...

Anyways, I wish you the best of luck on your project, which sounds really cool I might add.

Cheers
8  Forum 2005-2010 (read only) / Interfacing / Re: Gyro vs Accelerometer on: June 29, 2010, 11:22:58 am
Well I don't know much about the components, but I might be of some help with the concepts here...

Accelerometers do just what their name implies... they measure acceleration (as a swiping gesture with a Wiimote, or a car crash)... They can, however, also be used to measure orientation to some degree, since gravity is a constant force, and a sideways accelerometer will read different than an up-standing one...

A gyroscope, on the other hand, is a device for measuring orientation, since gyros spin really fast and spinning objects tend to retain their initial orientation, this can be used to measure relative orientation (and even absolute, if you have a gyro that never becomes misaligned)

The amount of measurements an accelerometer or a gyro can report is stated in degrees of freedom.

A degree of freedom is an axis about which you can displace  yourself... like moving left/right, or pitching up/down...
In 3D space there can be 6 degrees of freedom... those are left/right,  up/down, fore/aft (XYZ translations), Pitch, Yaw and Roll (XYZ rotations)

However, one might come across devices that say they can measure more than 6 DOF, like the 9DOF sensor from SparkFun... that doesn't mean it can measure hyperdimensional space (bummer)... but simply that it can measure absolute as well as relative displacements.

Now, on the difference between relative and absolute measurements...

Relative measuring is basically saying how much you displaced yourself from your previous measurement... no information of where you are can be known without a first (absolute) reference.

Absolute measuring is exactly the other part... it tells you where you are in relation to a wider scope (like magnetic north, or a fixed point in XYZ space), but how much you've displaced yourself since the last measurement would have to be calculated later.

So a device that states 9 degrees of freedom is probably an accelerometer coupled with a gyro and a compass for 6DOF relative measurement and absolute measurement of the 3 orientations so it gives you translation XYZ, pitch, yaw, roll, azimuth, zenith and... absolute roll (does it have a name?)

Now, on this notion, the maximum amount of degress of freedom one could have in 3D space would be 12, and include absolute and relative translations and orientations... Absolute position tracking is tricky, because it requires a frame of reference, which most people aren't willing to build on their living rooms... so a small 12DOF sensor is not something you can pick up at SparkFun yet, but if you do find one, please let me know so I can buy a thousand  smiley-wink  

I hope this helps... (and I hope I didn't write too much nonsense)

Cheers
9  Forum 2005-2010 (read only) / Interfacing / Re: I/O Remapping Chip... Does it exist? on: June 29, 2010, 08:49:53 pm
A pure code solution would be to have an array to hold your pins, with the array keys serving as 'virtual pins'... this way you can remap them at will just by changing the associated value of each virtual pin...

kinda like this:

int vPin[] = {3, 5, 6, 7, 8, 9} //these values are actual pins

so each output, or vPin, is just a reference to a real pin, but this pin could be changed whenever, via serial or any other way you want...

you'd write to a pin like this:

digitalWrite(vPin[1], HIGH); //sets the second output to HIGH

and read them in the same way.

Cheers
10  Forum 2005-2010 (read only) / Interfacing / Re: Position tracking using ultrasonic markers on: June 29, 2010, 04:24:05 pm
Quote
That assumes that there is no delay in getting something sent in a blue tooth package. There will be a delay and it won't be a constant one.

Yes, I'm aware of that. My idea is to send a timestamp to the emitter as the command to ping... this serves as a sync for the emitter, which then replies via BT with it's current timestamp at the moment of the actual ping, so the base station knows the time of ping not because of when the message arrived, but what time was written in the message.

To compensate the delay, once the message arrives, we start counting until we hear the ping, then get the time difference between the message sending time and it's arrival time, and add that into the measured ping time.

If all that fails, plan B is to not use BT, but some other form of radio communication with less or more constant delays.

Cheers
11  Forum 2005-2010 (read only) / Interfacing / Re: Position tracking using ultrasonic markers on: June 29, 2010, 02:59:33 pm
Quote
Hmm, sounds like you just had bad hardware or bad luck  

More like bad software actually... the program we were using wasn't made for LED tracking, so we were trying to do something with it that it wasn't made to do... and that led (  smiley-wink ) to all sort of problems...

Although it can be done using proper hardware and software... There are other problems associated with camera tracking, like lens distortions, perspective issues and general badness like that... So I'm on a personal quest to find a better, more reliable alternative... and I want to stay away from LEDs for that...

Apart from that, LEDs have another limitation in that you can't tell one apart from the other, save on very controlled conditions (like the TrackIR), and I want something more flexible than that...

Cheers
12  Forum 2005-2010 (read only) / Interfacing / Re: Position tracking using ultrasonic markers on: June 29, 2010, 10:10:17 am
Hi,

The object does not NEED to know it's own position... all data inference is done from the network up... (or should be at least)...

The idea is to have as little hardware on the emitters as possible, to keep them simple and battery powerable...

We're talking about meters in scale... I imagine something like a 3x3x3 meter volume.

About the LED idea, that's actually the reason I'm so obsessed with ultrasound tracking now... We built an LED tracking rig for a project a while back and it failed miserably... the cameras wouldn't pick up the LEDs, there were problems with light interference... horrible stuff really  :-X

So I started thinking about potentially more reliable ways of tracking absolute 3D positions, and it occurred to me that maybe a sonar-like approach could be a better option (I hope)

The rig is quite complicated... much more in fact than a camera-LED rig, but I'm hoping it should be quite more robust as well  :smiley

Cheers
13  Forum 2005-2010 (read only) / Interfacing / Re: Position tracking using ultrasonic markers on: June 28, 2010, 07:06:21 pm
Quote
I know that you can do this with a mesh of xbees and use the rssi to show signal strength.

This is an interesting idea too, I read about a project that used something like this (IIRC, it was wi-fi sig strength) to calculate your position using your local WLAN...

But trilaterating based on signal strength doesn't seem too realiable, does it? does signal strength decrease linearly?

In the project I was reading about the author had made a number of charts showing the results and how far off they were... He had to add a 300-cycle smoothing to get useable data...

Also, I worry about the refresh rates... suppose I have 3 markers (emitters) inside my space, and each is emitting pings for the sensors... that in itself might very well require 9 pings just to complete a calculation cycle... and even though a ping will take only about 10ms, that's quite enough to reduce the net framerate to below 10 fps...

There is a commercial system called Hexamite that uses this same principle to track objects in absolute 3D space... but as it seems it uses a complex sound analisys method to extract positional data... it's not a ping system...

This may yet need some thought...  :-?

Cheers

14  Forum 2005-2010 (read only) / Interfacing / Re: Position tracking using ultrasonic markers on: June 28, 2010, 02:56:21 pm
Quote
So how does the receive system know when a pulse was sent in order to measure the time it took to travel?

The receiver end tells the emmiter to ping via bluetooth, so when the command is sent, you can start listening for the ping...
Or, to prevent comm fails, maybe the emmiter could reply via BT just before pinging so we know the precise time of sending...

About the receiver/emmiter pair... maybe the quickest approach (and cheapest) would be to hack a PING))) sensor so as to disable it's emmiter... (and one with disabled listener for the emmiter)... IDK how easy would be to do that... it might not be as simple as snipping the leads off the transducers...

Anyways, thanks for the encouragement... I might just get to building this thing one day... and I'm gonna need all the encouragement I can get smiley-wink

About the array of rangefinders idea, I've thought about that... but decided it was too unreliable, since my puprpose is to track an object inside a volume, but the object could be anywhere inside that volume... plus, the separate emmiter/listener rig allows for other cool things like multiple emmiters.

Oh, and about the directional properties of ultrasound, I have a backup plan in case I can't find something that fits the need... I image a half-sphere positioned right above the emmiter, to deflect the ultrasonic wave in all directions... something like a halved ping-pong ball maybe  smiley-razz

Cheers

15  Forum 2005-2010 (read only) / Interfacing / Position tracking using ultrasonic markers on: June 28, 2010, 11:15:07 am
Hi,

So, I've had this idea growing on me for a while now, and have been researching the possibility and it seems more and more like it could work...

Basically, I'm trying to construct an active ultrasonic position finder, using separate ultrasound emmiters and receivers...

The idea is that a wirelessly-synced emmiter unit, would receive a wireless signal (probably BlueTooth) and emit a ping, that would be received by static "listeners", which have been set to listen for this ping... the time difference between arrivals then could be measured and trilaterated for position information...

The theory sounds sane enough to warrant a test... but my troubles lay in finding the right components for this... I wanted to find something like the PING))) sensor, but that would let me set it to listen for the ultrasonic ping, but without setting off the ping itself...

The PING))) can only rangefind by pinging and then listening for the echo, there's no way to make it only listen... But it is a very good sensor with a simple interface... I really don't wanna make my own sensors if it can be avoided...

And logically, I need something that can do the exact opposite, which is to send a wave, and not expect a reading itself...
This in itself presents a problem, which is finding an ultrasonic transducer that can emit a non-directional (or omnidirectional) pulse... All the transducers I could find are very directional, and I need something that can send off a sphere of ultrasound for the receivers to pick up...

So... Any thoughts?  smiley-wink

Thanks in advance,

Cheers

Pages: [1] 2