Author Topic: uBotino, a micro robot board (Read 9592 times)

Ro-Bot-X · « **on:** September 25, 2010, 01:02:25 PM »

After playing with the Robot Builder's Shield, I've decided to make a small robot board that has the same features as the shield. I wanted it to be 2"x2" (5x5cm) so it can be fabricated cheap and to be appealing to many robot builders that still build small robots.

I present uBotino. Features:

ATmega168 or 328 microcontroller
6 analog sensor connectors (analog pins 0-5, regulated power)
5 servo connectors (digital pins 9-13, power selectable to Vin or regulated Vcc)
SN754410 H-bridge, (digital pins 5-8, uses Timer0 for PWM)
5 digital sensor connectors (digital pins 0-4, regulated power)
3 pin hardware serial connector
FTDI cable connector for programming
6 pin ISP connector
reset button
jumper J1 to select power (5V or Vin) to the servo connectors
jumper J2 to enable/disable power to the motors (you don't want the robot to run all over when programming)
jumper J3 to enable/disable the LED on pin Digital 13 (don't use the LED when using a servo)
16 MHz ceramic resonator
power LED
power switch
5V LDO voltage regulator (1A or more)
small form factor, 2" square

uBotino can be programmed in Arduino or AVR Studio. I'll use the Board Designer to create a board so you guys can program it using WebbotLib.

Here are the pictures:

Webbot · « **Reply #1 on:** September 25, 2010, 02:19:19 PM »

Quote

I'll use the Board Designer to create a board so you guys can program it using WebbotLib.

Let me know if you want me to add it to the list of in-built boards.

Webbot · « **Reply #2 on:** September 25, 2010, 02:48:16 PM »

couple of observations 'off the top of my head':
1. Where is the 'FTDI connector'/USB?
2. Why J3 - what happens if you are using a servo as well
3. Good to have an extra user controlled LED if J3 is missing depending on answer to Q2 above. Can act as the WebbotLib error status as well as allowing people to write a 'blink the LED' program without extra hardware.
4. I2C connector?
5. A 3v3 regulator would be nice as many sensors are now 3v3

As I say: these are just observations and not criticisms - its all too easy to just 'add more stuff'.

Good job

Admin · « **Reply #3 on:** September 25, 2010, 03:29:44 PM »

I recommend a ~2kohm resister on the Tx line just in case the user inverts Tx and Rx accidentally.

No need to have more than one Rx/Tx header, as you don't want the user to have two devices plugged in to the same lines at the same time anyway.

Quote

5. A 3v3 regulator would be nice as many sensors are now 3v3

agreed

Ro-Bot-X · « **Reply #4 on:** September 25, 2010, 07:50:36 PM »

Thanks for your comments guys!

This board is something for a beginner that wants to build a simple robot using DC motors for driving, some sensors and some servos, perhaps for a pan/tilt or gripper. This board is not for a hexapod or biped. For a robot like that the Axon is the best choice. Roboduino does not have the h-bridge and having the FTDI on board raises the price. If one builds more than one robot, it's cheaper to have a separate FTDI cable for all boards.

To add 3.3v complicates things for beginners. Future versions may have it, but for now I think 5V is good enough as the usual IR and US distance sensors use that.

I did not add a separate I2C connector for the same reason, keep it simple and small. If one wants to use an I2C sensor he can split the cable in 2 separate 2 pin housings, plug the SDA, SCL in the proper analog pins and the Vcc, GND cable right behind them. The only think I was considering to add were the pull up resistors. Sometimes the internal pull ups work good enough, if not, perhaps they can be mounted on the slave board or make a hack and solder them under the board. If there will be a strong demand for these resistors I will add them to the next version.

The FTDI connector is on the right side under the Reset button. Since this connector is a SparkFun standard, it doesn't have the GND pin near the Tx/Rx pins, so I added a GND pin near these pins on the lower left side of the board. If a user uses a serial LCD all it needs is Tx, Vcc, Gnd, but if the user needs to connect something else, that GND pin near Tx/Rx makes an easy way to use a regular 3 pin cable. I know that you have to unplug it if you're also uploading code but it does make the connection easier. I'll add the 2k resistor in the next version.

Pins D9-D13 are either for servos or sensors. The LED on pin D13 is connected through jumper J3 so it does not blink when a servo is used on that pin. If the user needs all analog pins for analog sensors, pins D0-D4 can be used for digital sensors.

I used the Board Designer and got the uBotino168 board ready. Please take a look at it and see if it's done properly. If it is, I would love to have it loaded to the built in boards in Project Designer.

BTW, I noticed I marked the analog pins in the wrong direction on the silk screen (A0-A5 instead of A5-A0)... Oh well, I hope that's the only mistake...

Thanks!

Webbot · « **Reply #5 on:** September 25, 2010, 08:46:42 PM »

Have had a quick look at the board file.

There seem to be a lot of supplies ie each of the 4 motor values. This makes it messy when creating a new project from the board. I'm guessing that the motors get the unregulated battery supply and hence could be got rid of. A schematic would help - email one to me if you don't want to publish it yet as it would really help.

One thing I'll need to think about, for the Designers, is how best to cope with the jumper J1 for selecting the voltage to the header pins.

Ro-Bot-X · « **Reply #6 on:** September 25, 2010, 10:15:36 PM »

Here is the schematic. I removed those motor connections from the H-bridge to the motors and uploaded the file again in the same place. About the jumper, I have no idea how to deal with it in software. Perhaps check if a servo is added to those pins, then no sensor can be used and vice-versa.

Thanks Webbot!

BTW, I have some other ideas for boards and I need to talk to you about them. Also, I can send a PCB to you for free to test it out if you want to.

Webbot · « **Reply #7 on:** September 26, 2010, 07:26:46 AM »

Having looked at the schematic - here's an observation with the motor driver !

For each motor you are only supplying two inputs and the enable pin of the motor is always tied high.
This means that the pwm will alternate between full speed and brake which may cause the motor controller to get hot.

You are using the Generic PWM Motor driver which assumes the use of the tristate switch (ie a transistor and some resistors) to change the 2 outputs from the mcu to the 3 inputs of the motor controller - as per http://www.societyofrobots.com/member_tutorials/node/164.
This may give you an issue when speed = 0 as it will set the PWM duty cycle to 0% but the direction pin is changed into an input. So I'm not sure how the motor controller will re-act.

Alternatively the designer also has an SN754410 driver but that expects three mcu pins per motor rather than your two. The benefit is that the pwm will vary between full speed and coasting which should cause less stress to the motor controller.

Anyway I'm assuming that you've tested it all out anyway. Just an observation.

Ro-Bot-X · « **Reply #8 on:** September 26, 2010, 02:08:14 PM »

Well, I did not tested it with WebbotLib yet.

This type of motor connection I have used for years without problems. True, I did not had motors that would need close to the maximum supported current but it works. The only special thing in the software is that for reverse I need to issue an inverse PWM signal or substract the pwm signal from 255 and feed that to the motor. And to stop the motor I set both pins Low.

Here are the Arduino motor functions:

Code: [Select]

void Forward(){
  digitalWrite(Motor_1_Dir, LOW); // forward
  digitalWrite(Motor_2_Dir, LOW); // forward
  analogWrite(Motor_1_PWM, speed1); // 
  analogWrite(Motor_2_PWM, speed2); //
  return;
}

void Reverse(){
  digitalWrite(Motor_1_Dir, HIGH); // reverse
  digitalWrite(Motor_2_Dir, HIGH); // reverse
  analogWrite(Motor_1_PWM, 255-speed1); // 
  analogWrite(Motor_2_PWM, 255-speed2); //
  return;
}

void Right(){
  digitalWrite(Motor_1_Dir, HIGH); // reverse
  digitalWrite(Motor_2_Dir, LOW); // forward
  analogWrite(Motor_1_PWM, 255-speed1); // 
  analogWrite(Motor_2_PWM, speed2); //
  return;
}

void Left(){
  digitalWrite(Motor_1_Dir, LOW); // forward
  digitalWrite(Motor_2_Dir, HIGH); // reverse
  analogWrite(Motor_1_PWM, speed1); // 
  analogWrite(Motor_2_PWM, 255-speed2); //
  return;
}

void Stop()
{
  digitalWrite(Motor_1_PWM, LOW);
  digitalWrite(Motor_1_Dir, LOW);
  digitalWrite(Motor_2_PWM, LOW);
  digitalWrite(Motor_2_Dir, LOW);
  return;
}

Is there a way to set the same behavior in WebbotLib? What kind of motor driver I should choose so that it works?

Ro-Bot-X · « **Reply #9 on:** September 26, 2010, 02:20:51 PM »

I found the page that taught me the motor connections: http://www.barello.net/Papers/Motion_Control/index.htm

I am using the alternative method for Sign-Magnitude:

Quote

In sign-magnitude the controller sets the direction with the directions bits and then varies the amount of power to the motor with the PWM signal. Typically switching the ENABLE bit of the H-Bridge driver does this. The ratio of ON to OFF determines the amount of power going to the motor.

There is an alternative way to drive the motor: The Enable bit is left ON all the time. One half of the H-Bridge is set forward or backwards and the PWM signal drives the other half of the bridge. The effect of this technique is that the motor is alternatively driven and shorted with the ratio set by the PWM signal.

Ro-Bot-X · « **Reply #10 on:** September 26, 2010, 03:29:33 PM »

Ok, here is a robot I built to show off the uBotino board.

The robot has 2 GM17 motors, one micro servo, one SeeedStudio US sensor, 2 lever switches as bumpers, a speaker and an IR sensor for TV remote control. The robot listens to remote commands and drives around avoiding objects in it's path autonomously. The remote can play a song, drive, turn or stop the robot.

Here is the video:
[youtube]jtR88ssGZP8[/youtube]

And here is the code (note that I have used a custom Speaker libray for Beeps and song):

Code: [Select]

// Bot4Julia, a simple Start Here style robot, made with 2 CDs,
// 2 GM17 motors and wheels, one servo, one SeeedStudio US sensor,
// one battery box, one uBotino board
//
// uBotino board pinout:
//
// uBotino Funct Arduino  ATmega168      Arduino Funct uBotino
//                       +-----\/----+
//          Reset       1| PC6   PC5 |28  D19 A5  SCL  RightBumper
//          Rx    D0    2| PD0   PC4 |27  D18 A4  SDA  LeftBumper
//          Tx    D1    3| PD1   PC3 |26  D17 A3        
//          Int0  D2    4| PD2   PC2 |25  D16 A2        
//          Int1  D3    5| PD3   PC1 |24  D15 A1        IR sensor
//      Spk       D4    6| PD4   PC0 |23  D14 A0        Ping
//                      7| VCC   GND |22  
//                      8| GND  AREF |21  
//          Xtal        9| PB6  AVCC |20  
//          Xtal       10| PB7   PB5 |19  D13      SCK  LED      
//      M1A OC0B  D5   11| PD5   PB4 |18  D12      MISO 
//      M2A OC0A  D6   12| PD6   PB3 |17  D11 OC2A MOSI       
//      M2B       D7   13| PD7   PB2 |16  D10 OC1B      
//      M1B       D8   14| PB0   PB1 |15  D 9 OC1A      Pan servo
//                       +-----------+
//


#include <SoftwareServo.h>
#include <Speaker.h>

//Inputs/outputs
//#define Encoder_1_ChA  2 // digital pin 2    // Right Encoder
//#define Encoder_2_ChA  3 // digital pin 3    // Left Encoder

#define Motor_1_PWM   5 // digital pin 5    // Right Motor
#define Motor_1_Dir   8 // digital pin 8
#define Motor_2_PWM   6 // digital pin 6   // Left Motor
#define Motor_2_Dir   7 // digital pin 7

#define PingPin  14     // digital pin 14 (analog pin 0)
#define IR_Pin  15	// digital pin 15 (analog pin 1)
#define LeftBumper 18
#define RightBumper 19
#define PanPin    9     
#define SpeakerPin 4
#define LedPin 13

#define center 90

// Remote control buttons
#define btnPower   149
#define btnMute    148
#define btnPrevCh  187
#define btnDown    145
#define btnUp      144
#define btnLeft    147
#define btnRight   146
#define btnPlay    1434
#define btnStop    1432
#define btnRecord  1437
#define btnPause   1433
#define btnRew     1435
#define btnFwd     1436
#define btnInfo    186
#define btnSleep   182
#define btnInput   165
#define btnEnter   139
#define btn0       137
#define btn1       128
#define btn2       129
#define btn3       130
#define btn4       131
#define btn5       132
#define btn6       133
#define btn7       134
#define btn8       135
#define btn9       136

//Variables
byte dir=0;
byte speed1=230;
byte speed2=255;
int turn90=400;
int turn45=200;
int stopTime=200;
int USdistance=0;
int treshold=20; //20cm min distance

// remote control variables
#define start_bit  2200		// Start bit threshold (Microseconds)
#define bin_1  1000	        // Binary 1 threshold (Microseconds)
#define bin_0  400              // Binary 0 threshold (Microseconds)

SoftwareServo Pan; 
Speaker speaker = Speaker(SpeakerPin); 
//-----------------------------------------------------------------------------


void setup() { 
   
  // set motor pins as output and LOW so the motors are breaked
  pinMode(Motor_1_PWM, OUTPUT);
  pinMode(Motor_1_Dir, OUTPUT);
  pinMode(Motor_2_PWM, OUTPUT);
  pinMode(Motor_2_Dir, OUTPUT);
  Stop();

  pinMode(IR_Pin, INPUT); // uses an analog pin so it has to be declared as digital in

  pinMode(PingPin, OUTPUT); 
  digitalWrite(PingPin, LOW);
  
  pinMode(LeftBumper, INPUT); 
  digitalWrite(LeftBumper, HIGH); //turn on pull ups
  pinMode(RightBumper, INPUT); 
  digitalWrite(RightBumper, HIGH); //turn on pull ups

  Pan.attach(PanPin);
  Pan.write(center); //90
  StepDelay();

  pinMode(SpeakerPin, OUTPUT); 
  speaker.Beep();

  pinMode(LedPin, OUTPUT);      
  digitalWrite(LedPin, LOW);  

  Serial.begin (19200);
  Serial.println("start");

  Forward();
} 

void loop(){
  Drive();
  Get_IR_Command();
  //square();
}

void Get_IR_Command() {
  int key = getIRKey();		    //Fetch the key
  Serial.print("Key ");
  Serial.println(key);
  switch (key) {    
    case btnLeft:
      Left();
      delay(turn45);
      Stop();
      break;
      
    case btnRight:    
      Right();
      delay(turn45);
      Stop();
      break;
      
    case btnUp:
      Forward();
      break;  
      
    case btnDown:
      Reverse();
      break;

    case btnStop:
      Stop();
      break;

    case btnMute:
      speaker.PlayMelody();
      break;

  }  
  //StepDelay();
  return;
}

//--------------------------
int getIRKey() {
  int data[12];
  int newdata=pulseIn(IR_Pin, LOW, 100000);
  while(newdata>0 && newdata<start_bit) { //Wait for a start bit
    newdata=pulseIn(IR_Pin, LOW, 100000);
  }
  if (newdata==0) return 0;
  for(int i=0;i<11;i++){
    data[i] = pulseIn(IR_Pin, LOW, 100000);   //Start measuring bits, we only want low pulses
  }
  speaker.Beep();
  for(int i=0;i<11;i++) {	      //Parse them
    if(data[i] > bin_1) {	      //is it a 1?
	data[i] = 1;
    }  else {
	if(data[i] > bin_0) {	      //is it a 0?
	  data[i] = 0;
	} else {
	 data[i] = 2;		      //Flag the data as invalid; I don't know what it is!
	}
    }
  }

   for(int i=0;i<11;i++) {	      //Pre-check data for errors
    if(data[i] > 1) {
	return -1;	              //Return -1 on invalid data
    }
  }

  int result = 0;
  int seed = 1;
  for(int i=0;i<11;i++) {	      //Convert bits to integer
    if(data[i] == 1) {
	result += seed;
    }
    seed = seed * 2;
  }
  return result;		      //Return key number
}

void square(){
  Forward();
  delay(2000);
  Stop();
  delay(stopTime);
  Right();
  delay(turn90);
  Stop();
  delay(stopTime);
  Forward();
  delay(2000);
  Stop();
  delay(stopTime);
  Right();
  delay(turn90);
  Stop();
  delay(stopTime);
  Forward();
  delay(2000);
  Stop();
  delay(stopTime);
  Right();
  delay(turn90);
  Stop();
  delay(stopTime);
  Forward();
  delay(2000);
  Stop();
  delay(stopTime);
  Right();
  delay(turn90);
  Stop();
  delay(stopTime);
}

void Drive(){
  if (digitalRead(LeftBumper)==LOW){
  digitalWrite(LedPin, HIGH);  
    Stop();
    speaker.Beep();
    StepDelay();
  digitalWrite(LedPin, LOW);  
    Reverse();
    StepDelay();
    Stop();
    StepDelay();
    Right();
    delay(turn45); //turn45
    Stop();
    StepDelay();
    Forward();
  }
  if (digitalRead(RightBumper)==LOW){
  digitalWrite(LedPin, HIGH);  
    Stop();
    speaker.Beep();
    StepDelay();
  digitalWrite(LedPin, LOW);  
    Reverse();
    StepDelay();
    Stop();
    StepDelay();
    Left();
    delay(turn45); //turn45
    Stop();
    StepDelay();
    Forward();
  }
  USdistance=Read_Ping_Sensor();
  Serial.print("USdistance ");
  Serial.println(USdistance);
  if (USdistance<10){
    Stop();
    speaker.Beep();
    StepDelay();
    TurnAround();
  }
  if (USdistance<treshold){
    Stop();
    speaker.Beep();
    StepDelay();
    Avoid();
    Forward();
  }
  delay(50);
}

void TurnAround(){
    Reverse();
    Pan.write(center);
    StepDelay();
    Stop();
    Left();
    delay(turn90);
    delay(turn90);
    Stop();
    StepDelay();
    Forward();
}

void Avoid(){
  int prev=0;
  dir=2;
  for (byte i=0; i<5; i++){
    Pan.write(i*45);
    StepDelay();
    StepDelay();
    USdistance=Read_Ping_Sensor();
    if (USdistance>prev){
      dir=i;
      prev=USdistance;
    }
  }
  Pan.write(center);
  StepDelay();
  switch (dir){
    case 0:
      Right();
      delay(turn90);
      Stop();
      speaker.Beep();
      StepDelay();
      break;
    case 1:
      Right();
      delay(turn90); //turn45
      Stop();
      speaker.Beep();
      StepDelay();
      break;
    case 2:
      Forward();
      break;
    case 3:
      Left();
      delay(turn90); //turn45
      Stop();
      speaker.Beep();
      StepDelay();
      break;
    case 4:
      Left();
      delay(turn90);
      Stop();
      speaker.Beep();
      StepDelay();
      break;
  }
  delay(500);
}  

// Read Sensors
int Read_Ping_Sensor(){
  //digitalWrite(LedPin, HIGH);  
  int cm=0;
  //trigger the sensor
  unsigned long value = 0;
  pinMode(PingPin, OUTPUT);
  digitalWrite(PingPin, LOW);
  delayMicroseconds(2);
  digitalWrite(PingPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(PingPin, LOW);
  //receive the echo
  pinMode(PingPin, INPUT);
  digitalWrite(PingPin, HIGH); // turn on pull up resistor
  value = pulseIn(PingPin, HIGH);
  value=value/58;
  cm=int(value);
  //digitalWrite(LedPin, LOW);  
  return cm;
}

void StepDelay() {
    for (byte t=0; t<10; t++){
      SoftwareServo::refresh();
      delay(20);
    }
}


//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void Forward(){
  digitalWrite(Motor_1_Dir, LOW); // forward
  digitalWrite(Motor_2_Dir, LOW); // forward
  analogWrite(Motor_1_PWM, speed1); // 
  analogWrite(Motor_2_PWM, speed2); //
  return;
}

void Reverse(){
  digitalWrite(Motor_1_Dir, HIGH); // reverse
  digitalWrite(Motor_2_Dir, HIGH); // reverse
  analogWrite(Motor_1_PWM, 255-speed1); // 
  analogWrite(Motor_2_PWM, 255-speed2); //
  return;
}

void Right(){
  digitalWrite(Motor_1_Dir, HIGH); // reverse
  digitalWrite(Motor_2_Dir, LOW); // forward
  analogWrite(Motor_1_PWM, 255-speed1); // 
  analogWrite(Motor_2_PWM, speed2); //
  return;
}

void Left(){
  digitalWrite(Motor_1_Dir, LOW); // forward
  digitalWrite(Motor_2_Dir, HIGH); // reverse
  analogWrite(Motor_1_PWM, speed1); // 
  analogWrite(Motor_2_PWM, 255-speed2); //
  return;
}

void Stop()
{
  digitalWrite(Motor_1_PWM, LOW);
  digitalWrite(Motor_1_Dir, LOW);
  digitalWrite(Motor_2_PWM, LOW);
  digitalWrite(Motor_2_Dir, LOW);
  return;
}

blackbeard · « **Reply #11 on:** September 26, 2010, 05:14:41 PM »

that looks really nice! i also like the $4 price for the pcb! any idea how much you might sell a complete kit for? also have you considered adding one of those ftdi usb serial ports to it like on the arduino?

Ro-Bot-X · « **Reply #12 on:** September 26, 2010, 06:36:58 PM »

Thanks!

The board is programmable with a FTDI cable or FTDI breakout board. Or with xBees...
I did not added the FTDI chip on board because it raises the price and I have a problem paying for several FTDIs on several boards. One cable is good for programming several robots at a reduced price. Plus, like I said, it's easy to use xBees plugged directly in the same connector. So no, I will not add it on board. Other things I might add in a future batch, depending on the feedback I get on this batch.

I am currently searching for parts and I am trying to get all of them from a single distributor (Digikey or Mouser, Jameco, Futurelec...) so I don't have to pay 2 shipping fees (I live in Canada, shipping is expensive). This way I hope I can offer kits at lower prices than you will have to pay to get the parts from SparkFun.

madsci1016 · « **Reply #13 on:** September 26, 2010, 08:02:40 PM »

Quote

The effect of this technique is that the motor is alternatively driven and shorted with the ratio set by the PWM signal.

This is what Webbot was talking about, and I agree with him. A 50% duty cycle will cause the motor to be powered half the time, and dead shorted, braking, the other half. When a DC motor is shorted, there is a massive rush of current. This constant swelling of current will eat away at the brushes much faster then a motor run the 'non-alternative' way. Very small motors may not be affected much; the more mass is spinning, the larger the current when it's shorted.

For the next version of the board, if you still want to keep the number of IO the motor bridge uses low, i'd recommend using one pin for direction and use an inverter IC to create a 'not' of the single IO line. Then you could wire one side of the bridge to the pin, the other to the 'not' of the pin. This will set the direction of the motor with one pin, and then you can PWM the enable pin. The only downside is it removes the possibility of 'braking' the motor, but the same effect can be achieved by just running a motor in reverse to some power to 'slow it down'. This is how SAGAR's first motor controller worked.

Webbot · « **Reply #14 on:** September 27, 2010, 05:50:07 AM »

Quote from: madsci1016 on September 26, 2010, 08:02:40 PM

For the next version of the board, if you still want to keep the number of IO the motor bridge uses low, i'd recommend using one pin for direction and use an inverter IC to create a 'not' of the single IO line. Then you could wire one side of the bridge to the pin, the other to the 'not' of the pin. This will set the direction of the motor with one pin, and then you can PWM the enable pin. The only downside is it removes the possibility of 'braking' the motor, but the same effect can be achieved by just running a motor in reverse to some power to 'slow it down'. This is how SAGAR's first motor controller worked.

OR if you want to stick with just 2 I/O pins and have access to brake, coast, and PWM in both directions, and are prepared to add a few components then: http://www.societyofrobots.com/member_tutorials/node/161

Ro-Bot-X · « **Reply #15 on:** September 27, 2010, 06:04:07 AM »

Yes, that might be a solution.

Last night I tried to replicate the same program I wrote in Arduino for this robot in WebbotLib. I did not had time to go into detail, I just added the parts needed in Project Designer and generated the hardware code. Now I have to add the logic to it and last night I was too tired to do keep going.

How do I let PD know that the error codes can be sent to the LED? I added the led but I didn't had it as an option for the error codes.

How can I use a IR remote control sensor? Just have a digital input (active Low) and write my own code? Arduino uses a pulsein command, does WebbotLib has it? I guess it should, as it times the pulse length for Ping sensors...

What about the Buzzer? Is it supported to make Beeps in WebbotLib?

Thanks!

Webbot · « **Reply #16 on:** September 27, 2010, 07:44:16 AM »

Quote from: Ro-Bot-X on September 27, 2010, 06:04:07 AM

How do I let PD know that the error codes can be sent to the LED? I added the led but I didn't had it as an option for the error codes.

Give it the magic name of 'statusLED' and then it will get automatically registered as an error output

Quote

How can I use a IR remote control sensor? Just have a digital input (active Low) and write my own code? Arduino uses a pulsein command, does WebbotLib has it? I guess it should, as it times the pulse length for Ping sensors...

Check out the 'pin_pulseIn' in 'iopin.h'

Quote

What about the Buzzer? Is it supported to make Beeps in WebbotLib?

How is the buzzer driven? Some buzzers can just be switch on and off via an output pin (have their own fixed frequency), whereas others need PWM to generate a suitable frequency.

Ro-Bot-X · « **Reply #17 on:** September 27, 2010, 11:51:12 AM »

Thanks Webbot!

Will this code work for the buzzer? I mean it works in Arduino, but will it work in WebbotLib?

Code: [Select]

void Speaker::Beep(){
  unsigned long us;
  int duration_,i;
  int duration = 25000;
  int freq = 3000;
  us=(1000000/(freq*2));
  duration_ = (duration/(us*2));
  for (i=0;i<duration_;i++){
    digitalWrite(_pin,HIGH);
    delayMicroseconds(us);
    digitalWrite(_pin,LOW);
    delayMicroseconds(us);
  } 
}

I guess I need to replace the digitalWrite with something more appropriate and do the same for delayMicroseconds. Is there a nicer/better way to do it?

Webbot · « **Reply #18 on:** September 27, 2010, 12:18:39 PM »

Yeah that will work but you will need to change:-
digitalWrite => pin_set (see iopin.h)
delayMicroseconds => delay_us (see timer.h)

Of course thats just a direct replacement.

The existing code kills the machine as it waits while the beep is happening.
In WebbotLib you could use the generic pwm functions in 'pwm.h' to start the buzzer at a given frequency and then use the scheduler to turn off the buzzer after a given duration. In this way your code can carry on at full speed.

Webbot · « **Reply #19 on:** October 08, 2010, 01:03:07 PM »

Quick update for info

The uBotino (ATMega168 or ATMega328P) will be supported in the next release of WebbotLib and Project Designer.

Ro-Bot-X · « **Reply #20 on:** October 08, 2010, 05:46:29 PM »

Thank you Webbot!

Ro-Bot-X · « **Reply #21 on:** October 09, 2010, 10:47:51 AM »

Looks like the error output does not want to go to statusLED. I tried on an Axon, Roboduino and uBotino. The only option available is uart (or uart1 for axon). Am I doing something wrong?

Should I add the statusLED on the Board Designer or not? If I do, should I also add the J3 jumper and configure it to select the statusLED or nothing?

Edit: I noticed that the jumper can be configured only as a power selector. That's ok. Because of the way the jumper is connected, if one removes it, he can use a female-female jumper wire to connect the statusLED to another available I/O pin, in case a servo is connected to B5 (D13). So the user can edit the statusLED and change the pin to reflect the actual connection.

On the same note, I think I'll add jumpers to the H-bridge pins so the user can leave them on to use the hardware connection or remove them and use wire jumpers to rewire the H-bridge how he likes.

Webbot · « **Reply #22 on:** October 09, 2010, 12:01:15 PM »

I'm not quite sure why you have bothered with the jumper for the LED.

If you set it up in Board Designer then it will use pin B5. If a user is creating a project and they want to use pin B5 for something else then they can just click the disable box against the status LED. The fact that the LED will still flash depending on what they are doing with the pin doesn't really matter does it? The only thing the jumper does is to save a few milliamps but as soon as you connect 1 or more servos or motors then the current saving is next to nothing.

So if the user connects a servo to B5 and leaves the jumper in place then does it make any difference that the LED will still flash if they keep the jumper in place???

re your comment about letting the user rewire the LED to any pin header then the problem you've got is that you can't set it up in Board Designer as the user wont be able to change the pin on a per Project basis. So all you can do is leave it out of Board Designer. You are then leaving it up to the user to add it and to make sure its called 'statusLED'. So I think its too prone to user error.

My preference would be to add it to B5 in Board Designer and then let users 'disable' it if they want to.

RE how do you send errors to it ?
The errors are ALWAYS sent to the statusLED if there is one. Hence it doesn't appear in the list.

You can test it out by adding:
setError(5);
to your program. This should give 5 long flashes.
Your own error codes should be numbers > 0 (to give long flashes) whereas all of the WebbotLib internal errors are < 0 and produce short flashes.

RE Adding jumpers for the H-bridge. Again - why bother. All I would do is to add a new signal pin header for the 4 IO pins. They can then use those pins for other devices. Of course the commands are still sent to the motor controller but so what - if they dont have motors connected then nothing will happen. To use these new pins from Project Designer then all they would need to do is to disable one or both of the motors.

I don't like jumpers as people tend to take them off and then loose them!!

EDIT: Your schematic link in an earlier thread is now broken.

Ro-Bot-X · « **Reply #23 on:** October 09, 2010, 07:00:46 PM »

So I should not use the jumper for the LED and motors in the new version, right? The LED can flash when a servo is connected to the same pin and receives pulses, but it should not be used as statusLED at the same time. So if I can disable it then the jumper is not needed unless I want to use a wire jumper to rewire it to a different pin.

The errors puzzled me because it asked me to chose something and only uart was available. I thought that the statusLED would show up there as an option to chose from.

I fixed the link to the schematic, it was not working because I updated the schematic to have written the part values.

Thanks for the explanations!

Webbot · « **Reply #24 on:** October 10, 2010, 08:33:20 AM »

Quote from: Ro-Bot-X on October 09, 2010, 07:00:46 PM

So I should not use the jumper for the LED and motors in the new version, right? The LED can flash when a servo is connected to the same pin and receives pulses, but it should not be used as statusLED at the same time. So if I can disable it then the jumper is not needed unless I want to use a wire jumper to rewire it to a different pin.

Correct - Project Designer will not you use B5 for anything else unless you disable the statusLED

Quote

The errors puzzled me because it asked me to chose something and only uart was available. I thought that the statusLED would show up there as an option to chose from.

You will see that the combo box for errors is optional (ie it has a blank entry in the list). Errors always go to the statusLED if there is one. The combo box just lets you send the error message somewhere else as well - such as to a UART. This is just in case your board is inside a robot casing and you can't see the status LED.

Note that Version 1.27 has been released along with support for the uBotino (including new motor drivers for the way you've configured the motor controller).
Just try creating a new project in Project Designer. Don't add anything new - just save and then generate the project. Compile and upload. You should then find your motors turn backwards and forwards.

Webbot · « **Reply #25 on:** October 10, 2010, 09:12:15 AM »

One other observation about your schematic (and it applies to a lot of other boards as well).

The MISO, MOSI and SCK lines are used by the ISP programmer but are also available as header pins to plug in other devices. This can cause problems that you should be aware of:-

1. If you have a servo plugged into these lines (or any other device that receives inputs) then when you are programming the chip then these programming signals are also sent out to that device. Make sure you don't blow the servos !! To be safe you should disconnect other hardware from these pins whilst programming.

2. If you have another device that sends outputs to your board then you now have a contention whilst programming. Both the programmer and the other device will be trying to control the wires. At best the programmer may not work, at worst you may blow the programmer or the other device. One hardware solution is to add a resistor (1k to 4k7) in series from the processor pin to the pin header used by the other device. This makes sure the ISP drives the pins and isolates the other device. See ATmels application note http://www.atmel.com/dyn/resources/prod_documents/doc0943.pdf page 3.

Other solutions I have seen mentioned are to have a tri-state buffer between the processor pins and the non-ISP header pins that re-use them. When the processor is in programming mode then the buffer is tri-stated to effectively disconnect the other devices.

Just throwing this out there for consideration and in case you get problems reported by users.

Ro-Bot-X · « **Reply #26 on:** October 10, 2010, 05:03:16 PM »

Quote

Note that Version 1.27 has been released along with support for the uBotino (including new motor drivers for the way you've configured the motor controller).
Just try creating a new project in Project Designer. Don't add anything new - just save and then generate the project. Compile and upload. You should then find your motors turn backwards and forwards.

I did that and it works perfectly. Thanks!

The thing with the shared I/O lines with the programmer, I just remove the jumper that selects the power to the servos while programming with the hardware programmer. Most of the time I use the bootloader so it doesn't bother me, but I see what you mean. I'm not sure I can cram in everything on the same size board without going SMD. I'll look into SIP resistors, perhaps I can work something out.

Thanks again! It's good to see what problems might appear. A beginner may make a lot of mistakes. Even an advanced user might have mishaps.

Ro-Bot-X · « **Reply #27 on:** November 08, 2010, 06:11:05 PM »

You can now buy the uBotino PCB and kit from my webstore.

Version 2 of the board brings little change, just the motor connectors were moved to make room for the 22pF capacitors so people can use a crystal instead of a ceramic resonator. The kit includes a crystal and ATmega328. I have 8 kits remaining in stock, then I don't know if I can supply the microcontroller as I can't find it at a good price anymore.

You will also find in the store the Robot Builder's Shield for Arduino, which was designed for people that already have an Arduino and want to build a robot with it easier. It has mostly the same functionality as the uBotino. Version 2 of the shield brings a prototyping area, filtering capacitors, a Power switch and a jumper to transfer power from the battery to Arduino Vin pin.

Here are pictures of the 2 boards:

Crunchy Theory · « **Reply #28 on:** November 30, 2010, 12:44:41 AM »

Hi Ro-Bot-X, I just received your kit in the mail today - psyched to build it! Your guide/manual only includes information on how to get it programmed in the Arduino environment. Any information on how to get it running with WebbotLib? If I've missed something trivial, let me know - but I just finished my $50 robot and am new to WebbotLib.

Also, is http://www.sparkfun.com/products/718 this what I'll need to load my C program to the board? I am using OS X for development...

Thanks!

Ro-Bot-X · « **Reply #29 on:** November 30, 2010, 06:22:50 AM »

You're welcome. The WebbotLib tutorial is in the works, so wait a little and you'll have it. As for the FTDI programmer, I am using this one: http://www.sparkfun.com/products/10008 (I soldered a female header to it), or you can get this one: http://www.sparkfun.com/products/9716 or the cable: http://www.sparkfun.com/products/9718. They need to be at 5V and have that special pinout that works with all their Arduino boards and xBees.

News:

Author Topic: uBotino, a micro robot board (Read 9592 times)

Related Topics