Show Posts
Pages: [1] 2 3 ... 5
1  Topics / Robotics / Quick and dirty Wii-nunchuck-controlled kiwi drive robot on: July 10, 2011, 09:44:11 pm
A few months back I made a very simple Kiwi drive robot for a larger project, which has now been sitting on the back-burner for a while. I figured that it was high time I did something with it, so I wrote up a quick post explaining how I made it as well as the source code.
It's definitely not a "complete" project, but it's awfully fun to play with and hopefully it'll be useful to someone. Enjoy!
2  Community / Exhibition / Gallery / Re: Interactive talking Portal Turret plushie on: April 25, 2011, 05:55:17 pm
I really liked the Wave Shield, and would definitely recommend it for applications like this. I haven't tried adding an external amp, although I will be soon, because the sound is a little quieter than I'd like (it's great if you're in a quiet room, but as soon as there's background noise it's hard to hear).

For more sophisticated uses, I also recommend the rMP3 from Rogue Robotics. More expensive, but much more fully-featured.
3  Community / Exhibition / Gallery / Interactive talking Portal Turret plushie on: April 24, 2011, 12:17:28 pm
Leigh Nunan and I have made an interactive talking Portal Turret plush toy. It has a motion sensor, a lift sensor, and a tilt sensor so that it can react just like it does in the game (except for shooting at you). It's powered by an Arduino and an Adafruit Wave Shield. Pictures, video, and details (including source code) are available at the project page:
4  Forum 2005-2010 (read only) / Syntax & Programs / Re: 2D lookup table on: January 03, 2008, 09:37:38 pm
P.S. wouldn't my 16x16 table be:

int table [15][15]

because it starts at zero?


You declare arrays with their actual length (in this case 16), but index them starting at zero. So, with the 1D array:

int list[n]

The first entry is indexed as list[0] and the last as list[n-1]. It can be a little bit confusing at first, but it will seem very natural to you soon.  smiley-wink
5  Forum 2005-2010 (read only) / Syntax & Programs / Re: Arduino syntax highlighting for the web on: February 05, 2010, 07:31:04 am
Under edit, there is "copy as html" and "copy for forum."

Wow, I'd never noticed those commands before! What a nice feature!

That said, I still prefer the SyntaxHighlighter output: it has many more features and is completely configurable, so it can be made to look however one wants. Hopefully, someone else will find it useful, too.
6  Forum 2005-2010 (read only) / Syntax & Programs / Arduino syntax highlighting for the web on: February 04, 2010, 06:01:56 pm
I noticed there didn't seem to be Arduino-specific syntax highlighting available for web posts, so I wrote a couple of "brush" files for SyntaxHighlighter. You can see them at work and download them from my blog, here.

I wasn't entirely sure where to post this, so I decided the folder with "Syntax" was probably best; I apologise if that's wrong, and moderators please feel free to move it elsewhere.
7  Forum 2005-2010 (read only) / Syntax & Programs / Re: starting with spi questions about code on: March 11, 2008, 11:33:50 am
The hardware SPI, which you are attempting to work, only works on specific pins: SS is pin 10, MOSI is pin 11, MISO is pin 12, SCK is 13. That's a start, at least!
8  Forum 2005-2010 (read only) / Syntax & Programs / Re: Figuring out what compiles to more efficient c on: March 20, 2008, 03:32:02 pm

Thanks so much for the comprehensive (and quick) reply! Point by point:

Yes, constants are calculated at compile time, and the compiler is pretty good at recognizing things like the fact that (128 / 16) is the same as (128 >> 4) so will implement the fast bit shift instead of doing the division.

I'm not sure I understand: if it's calculated at compile time, then why does efficiency matter (other than compile speed)? If what ends up in the code is a constant regardless, why does it matter if it was calculated using division or a bit shift?

Looking at code size alone doesn't tell you anything about performance. In the same way as looking at the size of a car does not tell you how fast it can go, it's what's under the hood that counts.

That's what I guessed, regarding the code size - obviously loops and functions can decrease code size, but not execution time.

A good way to optimise code is to look at the assembler output from the compiler. But this is only helpful if you invest the time to learn to read and understand the assembler code.

I'm more than willing to do this; somewhat eager, in fact. I programmed a bit in assembler back in High School, and quite enjoyed it. Can you (or anyone else) suggest any good resources for learning about AVR assembler? Also, any tools for making examining the code easier (especially on OS X, but any *nix would be OK)?

...if you can take the code out of the ISR and run it in the loop of a sketch, you may be able to measure how changes to the code speed up or slow performance. Particularly if you measure over thousands or millions of iterations.

This has generally been my strategy for determining speed, but, of course, it has its limitations, which is why I'd like a less brute-force method.

Thanks again!
9  Forum 2005-2010 (read only) / Syntax & Programs / Figuring out what compiles to more efficient code? on: March 20, 2008, 02:54:05 pm
The project I'm working on is fairly timing sensitive: I'm using clock interrupts, and so the faster the ISR is running the better. I'm trying to make my code as efficient as possible; there are often several ways for me to accomplish the same result, but of course they'll compile differently, and some commands may take fewer clock cycles to execute than others. Is there any good way to figure out which commands compile more efficiently? Is simply looking at the size of the compiled code a reasonable indicator, or is that not a good measure?

For the same reason, I was wondering, if I include arithmetic operations which entirely use constants, will the result be calculated at compile time or at run time? (e.g., will 1 << 4 compile as 16, or will the bitshift get executed every time that code is run?)


10  Forum 2005-2010 (read only) / Syntax & Programs / Re: Cross Fade LED's on: January 22, 2008, 11:02:53 am
I've done something similar with a row of LEDs, along these lines:

#define FADEINCR 5 // step size; using 5 because that's what the original post uses
//Use chars to keep track of fade direction, because it is the smallest signed data type
char RedDirection = 1; // Red starts fading up
char OrangeDirection = 0; //Orange starts doing nothing
int RedBrightness = 0; // This starts red and orange off
int OrangeBrightness = 0;

void loop() {
    analogWrite(RedPin, RedBrightness);
    analogWrite(OrangePin, OrangeBrightness);
    RedBrightness += RedDirection*FADEINCR;
    OrangeBrightness += OrangeDirection*FADEINCR;
    if(RedBrightness > 255){ //If we've hit maximum brightness...
        RedBrightness = 255;
        RedDirection = -1; // ...switch to fading down...
        OrangeDirection = 1; // ...and switch orange to fading up.
    } else if(RedBrightness <= 0) { // If we're off...
        RedBrightness = 0;
        RedDirection = 0; // ...stop fading.
    // And again for Orange:
    if(OrangeBrightness > 255){ //If we've hit maximum brightness...
        OrangeBrightness = 255;
        OrangeDirection = -1; // ...switch to fading down...
        RedDirection = 1; // ...and switch red to fading up.
    } else if(OrangeBrightness <= 0) { // If we're off...
        OrangeBrightness = 0;
        OrangeDirection = 0; // ...stop fading.

Obviously, this won't run, it's just an outline. There are definitely ways to tidy this code up and optimize, but I left it this way for readability. I would also use an array for direction and for brightness, adjusted in a for loop, rather than having separate red and orange variables. If you need help adapting it, I can post the full code, but I figured you might want to figure it out on your own. smiley
11  Forum 2005-2010 (read only) / Syntax & Programs / Re: array processing -  any shortcuts? on: January 21, 2008, 01:56:09 pm
If the values of grid are from 0 to 255 then you can declare it as an arrray of bytes

Yes!  So do I use bitwise math?  I'm just learning this - not quite there, yet.

Can you give me an example?  Like, how do I get the values in and out so I can use them as ints in my logic?

No need for bitwise math: a byte is just like an int, except smaller (an int is two bytes attached together). It can hold a value between 0 and 255. If that's all you need, that you can use a byte exactly the same way you're using ints, but it'll only use half the memory.
12  Forum 2005-2010 (read only) / Syntax & Programs / Re: array processing -  any shortcuts? on: January 21, 2008, 01:44:23 pm
So, first of all, it looks like you already have commands to turn all of the elements on or off ("w x 100" and "w x 101"). And your "w b int int" and "w e int int" and other codes are similar.

But why not send "int int int int int int int int..." with as many as needed to update whatever it is you want, all in one go, and then have the Arduino distribute it out to the right place. If you're updated random segments of the total 1024 addresses in your system, you could start the transmission off with a 128 byte signal (1024 bits) acting as a mask; only the LEDs corresponding to the high bits are updated. Then have a byte at the end which has the value that you're assigning to them.

Admittedly, I don't know how often you're doing this or if the serial transmission rate is fast enough for your purposes, but you could probably come up with a scheme by which it could work.
13  Forum 2005-2010 (read only) / Syntax & Programs / Re: array processing -  any shortcuts? on: January 21, 2008, 12:34:44 pm
However looping through all the elements is really slowing things down since they all have to pass thu serial connection.

I don't know of any ways to do what you're asking, unfortunately (though I wish I did). However, the line I quoted above makes me wonder if there's a faster way to do what you're doing without addressing multiple arrays all at once.

Why do you have to pass all the data through the serial connection? Just extend whatever your serial protocol is to contain commands that allow you to address multiple points on your matrix at once. There's no reason to have more than one serial transmission to update the entire array.

If you'd like I could give a more specific example, if you post more details of your setup.

(By the way, I love your project!  smiley )
14  Forum 2005-2010 (read only) / Syntax & Programs / #define vs variables? on: December 23, 2007, 11:49:10 am
I'm almost positive this must have been discussed somewhere before, but my searches didn't turn anything up, so my apologies.

I was wondering why it seems to be the convention here to use integers to define pin mappings. Wouldn't #define be more space efficient, since the pins presumably aren't changing? And, if there is a good reason for using a variable, why not use a smaller one, like a byte, rather than an int?

That said, in general, why should one use a #define over a variable, and vice versa?

Thanks for indulging a newbie!  smiley
15  Forum 2005-2010 (read only) / Interfacing / Processing serial.write command slow; any ideas? on: March 19, 2008, 08:28:11 am
I need to send data to the Arduino quickly, and my messages weren't getting processed as fast as I expected. I assumed the problem was in my Arduino firmware, but, after much debugging, I realized that the problem was on the sending end. It turns out that Processing takes a full millisecond in between serial write commands, regardless of baud (at least on my Mac 10.5.2 2.33Ghz machine). Since the messages are received correctly, the actual message is being sent at the correct speed; it's just that the overhead of the command seems to be ridiculously high.

Does anyone have any ideas how to fix this? If not, what's a good alternative for my computer-side software? I fear I may need to switch over to C, which will make my life a little more difficult, but I suppose learning to do Serial I/O in C would come in handy eventually.
Pages: [1] 2 3 ... 5