http://arduino.cc/en/Hacking/LibraryTutorial

My favourite is:

Code:

#define EVER (;;)

// then...
for EVER;

Hehe.  I like that.

What type of servos were you using?  Not all servos are created equal.  What sort of positioning resolution do you  need out of the system?

The micro gear motors are only going to be half of what you need.  The motors themselves have no positional control to speak of.  You'd need some form of encoder feedback and then a controller to handle positioning of the motors, not a trivial task.  So actually, they're only about a third of what you need.

What you may want to do is look at the dynamixel servos.  They may provide the control you need.  They will not work with the sparkfun pan/tilt, but Trossen Robotics provides a dynamixel compatible pan/tilt platform as well as the dynamixel servos themselves.

If you want to be able to handle more than 6 buttons, the code will get a bit more complicated as the USB Keyboard protocol only allows registering up to 6 keypresses at the same time (this is why the Teensyduino keyboard class has six separate methods for issuing a keypress).

Up to 6 buttons can be done fairly easily by duplicating this block of code:

Code:

boolean boolBtnUp = !digitalRead(pinBtnUp);
 
  if ( boolBtnUp )
  {
    //Set key1 to the U key
    Keyboard.set_key1( KEY_U );
  } else {
    Keyboard.set_key1( 0 );
  }

up to six times, changing the set_key# function that is called for each one, from set_key1() to set_key6().  As I said at the beginning though, writing code to handle  10 buttons becomes a non-trivial task (and you still would not be able to register more than 6 button presses at any one time)

simply believe it is better to avoid putting the "RTC.refresh ()", solving with something that just works without requiring you to manually refresh, so I thought of the thread.

That can be solved using one of the hardware timers.  Look at the Timer2 library in the Playground.  You'll see that, once it's set up to run at some interval, there is no regular 'refresh()' call required in the main loop.  Threads are not only not necessary, but the complete opposite of an elegant and clean solution to a rather simple problem.

Though to be perfectly honest, the perceived issues with using a refresh() call in the main loop are questionable as well.  The whole point of loop() is to execute code over and over and over, so any objections to using it for that purpose are objections to it's whole existence.

Utilizing a hardware timer requires the use of an Interrupt, which has it's own suite of snares and hurdles to deal with, and should really only be used when real accuracy is required, and I can't think of anything involved with controlling an aquarium that would require more than second resolution accuracy, never mind millisecond or microsecond resolution accuracy.

So, to put it simply, I simply believe it is better to use an RTC.refresh().  You're creating a problem where there isn't one, and looking for a solution that is more complicated, more error prone, and more obtuse.

1.The code above controls only two motors, when I control four motors, where should I change?

When dealing with fixed orientation motors/wheels, controlling four motors is the same as controlling two motors, because you should be controlling the motors in pairs.  There's no reason for the two motors on the left side to be driven separately (same for the right side).  Ideally, just wire the two left motors in parallel to the motor controller (making sure the motor controller can handle the current of two motors), and then wire the two right motors in parallel to the motor controller.

http://arduiniana.org/libraries/tinygps/

I was describing the behavior when the USART has not been enabled, as that was the original posters question regarding how prints work without any call to begin().  If the USART has not been enabled, then the UDRE bit of UCSRA register will always be set, because the USART will not spend any time shifting out any data, and in fact won't even bother clearing the UDRE bit when you push a byte into the UDR register.

If the transmitter is enabled, then it's a completely different story.

I find it hard to believe that code will ever stop the motor for several reasons.

1.  Your encoder0Pos needs to be declared volatile.

2.  You are checking your encoder0Pos value in your stop1000() function, but you only call that function 1 time when you receive an A character.  You need to be checking the value repeatedly until your stop condition has been met.

3. You're only stopping the motor when encoders0Pos exactly equals 1000.  You can't be guaranteed that the code will perform the check when the encoder value is exactly 1000.  If Encoder0Pos equals 1001, then you've missed your small window for stopping the motor.  A better approach would be to stop the motor when Encoder0Pos is greater than 1000 (but of course, you still need to be repeatedly checking the value)

2) Even if they go nowhere, at 9600 baud, they delay your program by over 1ms per character.

If the USART Transmitter has not been enabled, then it will not spend any time shifting out any characters put into the Transmit register.  The Data Register Empty and Transmit Complete flags will always be true.  The only time that will get consumed is the write operation pushing characters into the Transmit buffer and waiting for the UDRE flag to get set (which will always be set).  This still takes some time, but it'll be on the order of a few microseconds per character.

That being said, it's still a poor method of enabling/disabling debug messages.  The method westfw presents is far better (and doesn't prevent you from using the serial port for other purposes as well).

I looked at the Playground myself, and it seems like an appropriate place to put the tutorial.  However, it says you have to request 'Contributor' access to submit stuff to the Playground, and the page to request such access doesn't work for me.  Instead of getting a form, I just get "(:registerform:)"

One thing I've noticed over the last few months is a considerable number of threads on problems reading and processing serial data on the Arduino.  So I've been working on a fairly extensive tutorial on the subject.  It's nearly at a final draft state, so now I'm looking for two things:

1.  I by no means consider myself an expert on the subject, so I would welcome (and even prefer) to have some other experienced members of the forums review my final draft and provide feedback/comments.  This is also the first tutorial I've ever written, so I have no idea how good it is as a tutorial.

2.  I am looking for recommendations on where to put the Tutorial.  I don't have a website or blog or anything like that to post it to.  I could always just submit it as a topic in the forums, but I would prefer putting it someplace with a bit more... permanency.

You are asking for a considerable amount of information here

http://www.societyofrobots.com/step_by_step_robot.shtml

That link should give you an idea of just how much information you're asking for.  It's got nothing to do with the dfrobot 4wd platform you are looking at, but it should give you a much better idea of what's involved with building a robot piecemeal or from scratch.

To put it simply, you shouldn't be doing what you are trying to do.  Stick to predefined array sizes within your structs.  Even when used properly, flexible array members are considered poor programming practice, and using them properly requires dynamically allocating your structs.

Applying the fix would be:

Code:

struct s {
 
  char c;
  int i;
  int pattern[5][5];
 
};

Yes, that means the struct is hard coded with a 5x5 pattern array, but unless you fully understand how to use flexible array members you shouldn't use them.

Arduinos cannot be programmed using pbasic.  You need to learn 'that C style language'.