Baby O 168 controling motors precisely

I have been working a babyO 168 - 2 motor project which involves time delay to move and position the motors.
the standard delay(ms) will not return the motors to their
original position.

I wish to use a more precise method of moving motors such as touch sensors.

sensor one is reset
motor1 turns
motor1 phyiscally triggiers sensor 2
motor1 stops
motor1 reverses
motor1 triggers sensor two
motor1 stops at original position.

thats two sensors per motor and 2 motors which makes 4 sensors possible 8 leads.

is the babyO capable of this, and do you have any ideas to enhance performance?

please advise


You haven’t really described your setup, but the Baby Orangutan can definitely stop and start a motor in response to an input. Measuring sensors and driving motors in a programmable way is pretty much exactly what a robot controller is designed for.

There are several ways to achieve repeatable motion. If you just want to prevent the motor from moving too far, use a “limit switch” - a basic momentary-contact switch. Lever-arm switches are particularly nice as limit switches. If you want to rotate your motor to a variety of specific angles, and you are okay with a 180-degree range of motion, you can use an R/C servo, which uses a potentiometer as the sensor. If you need to reach various specific positions over many rotations of the motor, you might use a wheel encoder - a mechanism using an optical sensor to count how many times a particular shaft has turned since the circuit was turned on. With wheel encoders, you might need to have a way of setting your zero point every time, and a limit switch is a good way to do this.

I hope that helps! If you can describe what you need a bit more, maybe we can give you some suggestions.



thanks for getting back

I am looking to limit the travel of the motor(s) in forward and reverse and replace the old delay() functions, the momentary level arm switch looks like a possibility as long as they are small and compact.

programmatically speaking i would need a routine that listens in the background for the trigging of these switches
is this possible with the AVR studio and “C” language.

Also do you sell these switches, the smaller the better.

thank you


Hello Dave,

Unfortunately, we don’t sell any switches like that here. You can try places like Mouser Electronics for them - looks like they have 99 pages of limit switches!

While you’re waiting for your switches, you should read up on doing bit tests to determine the state of inputs, as well as enabling the pull-up resistors. This will allow you to easily replace your delay_ms() function.



thank you

I will look in to the items you mentioned and get back to you with feedback later


If we take one step at a time
i will need help with selecting the proper switch for the application i am working on
as i am not familiar with the switch specs, gf, spdt, dtsp, and so forth, and i would not want to purchase the wrong item. I will give you more details as to what i need.

These are the motors i am using
The baby O

weapons control round load action for a 1/16 scale model tamiya TIGER I tank

motor 1 opens and closes a munitions door.
motor 2 moves an arm fw and bw to position a round.
I am using 2 “PC” ports on the babyO which is controlled by a R/C transmitter to
start the cycle. the cycle runs once, resets, then waits for another transmitter command.
The basic “C” program has been written and tested using “delay_ms” functions.

as i mentioned i wish to replace the delay_ms functions with switch trigger sensing functions
to more accurately control the the motors.

limit switches??:
Senses if a motor action has triggered.
The switches should be as small as possible and relatively easy to trigger with minimal strain on the motors. Yet the switches should not trigger by the normal movement and vibrations of the tank.
I do not know weather the switches should be spdt or dtsp? I would think as simple as possible
2 connectors. They do not have to have the ability to auto reset as this could be done by software. But perhaps there is an advantage for the switches to be able to reset them selfs, i don’t know.
Also the switches should be compact and easy to mount. the mouting may vary and depends on motor/arm action travel.

your advise as to the switch that should be used


From your description, it sounds like you really should be using a couple of R/C servos, not a motor with limit switches. A servo can turn to a specified angle and hold its position, which should be totally fine for moving a small door or an arm. It’s easy to control two servos with the Baby Orangutan, so is there any reason you aren’t using them?

If you really want to go with a limit switch, take a look at the wikipedia article on switches for the definition of things like DPDT. Probably you’ll get a SPST or SPDT switch, but any kind of momentary switch will work for you, since the Baby Orangutan can easily be programmed to look for any kind of transition.



i have considered using servos, i did not believe they would work in this application.
( there is a height space constraint also i forgot to mention, a compact design is import )

Here is more detail on Motor2
Motor-2 turns a shaft which is connected to a threaded rod(2-56), which is connected to a threaded nut (2-56), which is connect to a perpendicular arm, which pulls/pushes a round to the end of the barrell where the round is ignited (a round is really a modified bottle rocket the end of the barrell has a mini glow plug to ignite the round). the shaft turns threading the nut in/out - forward/reverse. Motor2 has to make an estimated 20 or more turns to thread the nut-arm in/out. Perhaps a servo could be used but a servo can only to 360 turn once.
the servo would have to have a large toothed gear with a ratio that pull/push the packing arm. the diameter/swing of that gear or servo arm would also take up more space.
I am using the threaded rod method to also help make the system work in a very small constrained space.

Motor-1 opens the barrel door. The barrel is nothing more than a 1/2" brass tube with
a cut opening for a round to fall in. The door is actually another halved brass tube slightly larger than 1/2", that fits over 1/2" tube and turns 360 forward/backward. there is a 20 toothed gear that fits over the door tube. Motor 1 sits above and away from the door tube and engages direct drive on the toothed gear. when the Motor 1 turns it opens and closes the brass tube door. Again here there is a space constraint , here there are no swinging arms, everything is compact and contained.

I’ve included a photo.

do you believe servos could accomplish this task more efficiently?


Wow, that looks nice and compact. I wish the picture was in better focus so that I could see what was going on, but it does look like you know what you are doing on the mechanical side - if the motors are working for you in that assembly, I would stick with them. By the way, an alternative to limit switches is to just have a physical stop so that the motor hits it and stalls. Have you considered doing it that way? Then you could just stick with the old delay_ms()-based code.



I am sorry about the photo but I have more so you can see better.

Stalling motors? never heard of this. Are you saying that the BABY-0 can sense when a motor is under strain?
And this strain would act as a trigger?

My only concern would be damage to the motors if they were to truely be over strained or purhaps damage to the
surrounding structure. But if there is no danger of damage taking place then yes this would be a possibilty

Paul here are some better photos

Thanks for the additional pictures - I think I am starting to get a better sense of what is going on. In general, yes, you want to avoid stalling motors, but if you run them at the lowest possible power and only stall them for a short time, it might not cause trouble in your setup. For example, if it takes the motor between 100 and 150ms to close the door, you could just wait 200ms to be safe, and it would close every time, stalling for a short time. Sometimes it makes more sense to do that than use a limit switch, but it depends on your setup.



I see i understand. I do not believe this will work ( stalling ).

I cannot run the motors at the lowest possible speed. If i went with lowest possible speed,
it would take forever to complete the cycle, esp for motor2 . 2nd the speeds and distances
the motors travel will need constant adjusting for the process to work perfectly, it would be better
for the process to be auto adjusting hence the limit switch method. Again going by delay_ms
will also require lots of trial and error to fine tune the cycle. Also I do not want to risk over taxing the motors
as they will be required to perform this task 1000’s of times.

I believe i will want to stick with the limit switch method for these reasons mentioned above.

I believe i will want to go with small momentary(4) low power switches …

I will require advise as to Port/wiring and baby-O programming to sense the
triggering of the switch. The BabyO should have enough spare ports for this.

can you provide a simple example


Sure, there is an example in the documentation for our 3pi robot:

That shows the circuit for connecting one button or switch to port PB1 on the AVR. You can use any of the general purpose I/O pins, each of which has an internal pull-up resistor, so you only need to connect the pin through a switch to ground. (You don’t need the 1k resistor shown in the diagram; that is there because PB1 is also used as an output on the 3pi, and doing so at the same time as pressing the button would otherwise cause a short circuit.)

The pins are inputs by default, so to use them you just have to enable the pull-up resistor, then enter a loop and start testing the pin:

PORTB |= 1 << PB1;
  // test the switch
  if(PINB & (1 << PB1))
    // switch is open - do something ...
    // switch is closed - do something different ...

If the bit logic commands here don’t make sense to you, search Google for bit tests on the AVR, and you will probably find plenty of helpful tutorials.



i belive i have the basic idea i would like to review/recap.

So one lead of the switch would be wired to one PINB1 B2 ect …
and the other lead of the switch would be wired to ground or “-” (negative) ?

Can you look of the comments to see if they are correct?
Do you have any suggestion to improve code/efficiency/readability/functionality


int Switch1Listen() {
PORTB |= 1 << PB1; ### does this reset PINB1 ?
while(1) # loop forever
  // test the switch
  if(PINB & (1 << PB1))  ### Tests to see if switch is closed
    break;       # Stop Loop
    // switch is closed - do something different ...


int Switch2Listen() {
PORTB |= 1 << PB2; ### does this reset PINB2 ?
while(1) # loop forever
  // test the switch
  if(PINB & (1 << PB2))  ### Tests to see if switch is closed
    break;       # Stop Loop
    // switch is closed - do something different ...

is there a way of running “C” moduals or routines in the background ( background processing )


Sorry to have left you hanging - I somehow missed your post and didn’t get back to you.

Anyway, did you learn what the bit operations, PORTB, PINB, etc. all mean? Because the comments in the code you posted made it sound like you don’t really understand it. Here’s a link to a post with a nice discussion of the different bit operators. Beyond that, what you need to know is that when the port is used as an input (the default):

  • The PINB bits are 0 when the input voltage is 0 and 1 when the input voltage is 5 V.
  • The PORTB bits control the AVR’s internal pull-up resistors, which cause the input to be at 5 V if it is not connected to anything else.

Does that make sense? Anyway, if you are still confused about how to make this work, here’s another potentially useful tutorial. Beyond that, I really recommend looking at the datasheet for the mega168, where you can see in extreme detail what everything means.



It is quite already i know you are busy. Many thanks for your advises.

C programming I am familar with but bit wise logic i never had a handle on, I still do not fully understand how the bit wise logic
pertains to the pins and popup registers, this is something I will struggle with until I understand it fully.

In review of my project i am now considering to use one servo to replace motor1. I will still keep motor2 and the switch(es) for motor2.
You mentioned a servo could be easily controlled by the Baby-O(168) in terms of degrees. Can you advise a simplified article how the baby-0(168) can control a servo.

many thanks