Results 1 to 8 of 8

Thread: Hexapod walking disturbance due to to pulseIn() commands

  1. Hexapod walking disturbance due to to pulseIn() commands

    Friends im having a problem with hexapod walking. thant th epod becomes extremely slow and takes just one step too late when im using the pulseIn()command.

    the scenerio is that i have interfaced three maxbotics ultrasonic sensors with the Arbotix digital IOs. to read the data i used command pulseIn(pin, tranmission). this makes my pod extremely slow.

    int pwPin1=1;
    void setup()
    digitalWrite(pwPin1, INPUT);
    Serial.begin (9600);
    //boiloid function
    void loop()
    sensor1=pulseIn(pwPin1, HIGH);
    Xspeed= multiplier*40/5
    //remaining code of original HexapodMarkII code provided by trossenrobotics
    this makes the pod extremelyyyyyyyyyyyyyyyy slow.

    however when i used the command as:

    sensor1=pulseIn(pwPin1, HIGH, 0.00001);
    the pod moved perfectly but the serial monitor "0" output from the sensor.

    there seems someproblem of using timeout argument in pulseIn command.

    can anyone plz pick out the mistake and rectify the problem.

    plz be quick

  2. #2
    Join Date
    Apr 2014
    State College, PA, US
    Rep Power

    Re: Hexapod walking disturbance due to to pulseIn() commands

    I think that your problem is because the Pulsein actually waits for the pulse to come in, which can be long enough that it messes up your walking routine.

    I have a couple of suggestions.

    1. Could you use an interrupt routine rather than the Pulsein()? In this routine you'd put the pulse length into a global variable and return. The main routine would just check the value of the routine.

    2. Have a separate microcontroller handle the sensors and the main controller would communicate with it periodically via I2C or something. For emergencies the sensor controller could have an interrupt line to say "hey, you're about to fall over or something!"

    I tend to use a combination of the above, but that was a while ago. I'm a bit rusty with coding now.
    A little learning is a dangerous thing.

  3. #3

    Re: Hexapod walking disturbance due to to pulseIn() commands

    A couple of things, first if you do pass in a timeout, it is an unsigned long value in microseconds, so you passed in 0, which will always timeout...

    The guts of pulsein command boils down to 3 loops. First it waits until the state you pass in for high is true as to make sure it will see the start, then it waits until the pulse value goes logically true, then it counts how many loops until it goes logically off, and then it returns the count converted to microseconds...

    Again whenever I wonder what one of these commands does, I go look it up in the sources... In this case I looked at:
    C:\Program Files (x86)\Arduino\hardware\arduino\cores\arduino\wirin g_pulse.c
        while ((*portInputRegister(port) & bit) == stateMask)
            if (numloops++ == maxloops)
                return 0;
        // wait for the pulse to start
        while ((*portInputRegister(port) & bit) != stateMask)
            if (numloops++ == maxloops)
                return 0;
        // wait for the pulse to stop
        while ((*portInputRegister(port) & bit) == stateMask) {
            if (numloops++ == maxloops)
                return 0;
    The copy in the Arbotix folder should be the same...

    Not sure how you have your sensors wired in. Do you have them in continuous mode, with them wired to daisy chain or do you have them set to be triggered? ... if in continuous mode, you very much run the risk that you could start your call to pulsein, in the middle of a pulse and the code will wait until that pulse completes, then wait for the next complete pulse cycle, which could be awhile...

    What to do about it?
    1) As mentioned, by DangerousThing, you could go to using interrupts, such as the pin change interrupt. In continuous mode this is probably the easiest way.
    a) If you can use pins 0-2 I believe you can use attachInterrupt for these pins on the Arbotix
    b) You can use the Pin Change Interrupt on all pins on Arbotix. There are libraries on net for this, but they do not coexist well if you are using the library SoftwareSerial as SoftwareSerial claims all Pin change interrupts for itself.

    2) Time your calls to pulsein as to not interfere, Not sure what your rest of the code is. If it is the standard Nuke code base, then I am not as much help. With the Phoenix code base I made my own version of the Bioloid library code, where my calls to InterplateStep do not necessary stay in the call until the next time to update the servos, but can instead, check to see if it is time to do the interpolate (or very close to that time) and if not can return how much time, until the next interpolation. Some places in my code, I will then check to see if there is sufficient time to do some other task such as ask a servo for it's battery voltage...
    With the unmodified code, you can probably also add stuff to loops like:
        while(bioloid.interpolating > 0){
    As the call to InterplateStep will have just completed it's output to the servos... But again if you have the three sensors wired up to fire one after the other, and you do a call to pulsein on a servo while it is pulsing, it may take a long long time to return.

    Last edited by KurtEck; 05-26-2014 at 08:44 AM.

  4. #4

    Re: Hexapod walking disturbance due to to pulseIn() commands

    I recommend hooking up a pin change interrupt to the pin in quesiton, and then having the interrupt handler store the time of the rising and the falling edges into some global variables, and set a flag when the falling has been seen.
    You would then read something like:

    on setup, install the interrupt handler
    is it time for a reading?
    if so, turn on the sensor through a short pulse out
    if the global ready flag is set, calculate the distance as stop_micros-start_micros, and clear the global ready flag
    in interrupt handler
    if rising, store the value of micros into start_micros
    if falling, store the value of micros into stop_micros and set the global ready flag

  5. Re: Hexapod walking disturbance due to to pulseIn() commands

    i think that would miss my data. because the pulse is noting but the distance sensor is sensing and its on time is the time uptill when the distance is sensed i think. edge detection wouldnt then miss my useful data!!??

  6. #6

    Re: Hexapod walking disturbance due to to pulseIn() commands

    Actually in this case, you are using the Interrupt as well as the system timer to find when the each of the pins change state. If you remember the time when the pulse went logically high, and again when the pulse goes logically low, and subtract the two, you then have the pulse width.

    On the web there are examples of how to do this. For example with the Phoenix project, one of the Input devices I have some support for is for RC receivers. With this I have a version of the PinChangeInterrupt library, that I modified. Don't remember all of the changes, but I know that it has support for Atmega328(Arduino), Atmega644p(Arbotix)... Also I think I made it somewhat configurable, in which of the interrupts it will claim. I also at one point updated the SoftwareSerial code as well as if you include SoftwareSerial, it will claim all of the Pin Change Interrupts, even if you only need one of them...

    If you wish to see this version of code, it is a part of My Arduino Phoenix in Parts project:


  7. #7

    Re: Hexapod walking disturbance due to to pulseIn() commands

    edge detection wouldnt then miss my useful data!!??
    Check the fifth line in my proposed code:

    if the global ready flag is set, calculate the distance as stop_micros-start_micros, and clear the global ready flag
    This calculates the duration of the incoming pulse (edge to edge) without having to block the CPU while waiting for the edges.

  8. Re: Hexapod walking disturbance due to to pulseIn() commands

    Thanks alot. i have successfully interfaced 5 obstacle avoidance sensors with the pod using Analog channels. the pod is avoiding obstacles quite accurately.
    Now i want to interface GPS and heading sensors with the pod for its autonomous guidance and navigation. For that i used APM 2.5 ardupilot kit. im receiving this data through Hardware serial. (i tried but dont know why i couldnt receive it through software serial).
    once again i fell in the same issue of legs' movement delay
    it waits untill the whole packet is received and thus the servos movement has been extensively slowed down.
    i tried to get it through INT2 interrupt by setting CHANGE mode but it was not received as an interrupt.
    i would like to share what i did:
    i used the example from Communication folder of Arduino examples. the code was :multiserialmega". in the setup loop i used attachinterrupt for get_serial function. such that the command is:

    attachinterrupt(2, get_serial, CHANGE);

    on hardware side i have made "short connection" for interrupt at 'PB2' and 'pin2 on XBee module base' (XBees are not being used).

    what happend is that the data is being looping back only.
    i retried by commenting the serial.print command in get_serial function, still the data was looping back.

    can anyone plz indicate the error and help suggest some solution

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. MX-64T occasionally misses commands
    By jwatte in forum DYNAMIXEL & Robot Actuators
    Replies: 0
    Last Post: 11-10-2013, 05:52 PM
  2. Project Mantis - Two Tonne Turbo Diesel Hexapod Walking Machine
    By mdenton in forum Project Showcase
    Replies: 22
    Last Post: 06-24-2013, 08:49 AM
  3. Bot not walking
    By chaitanya in forum Humanoids, Walkers & Crawlers
    Replies: 4
    Last Post: 09-24-2011, 09:58 AM
  4. Question(s) HB-25 Missing Commands
    By ROBOTMAN in forum Arbotix, Microcontrollers, Arduino
    Replies: 5
    Last Post: 05-08-2011, 07:06 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts