It is possible that your interrupts are too long and crash more often when you do it at 10ms... You can measure your interrupt time using a timer (without interrupt) and look how many step you have at the beginning and at the end (just reading the timer value). The "advance one timer" is controlling the motor using only one timer for all motors and other stuff using an agenda. It is in the library under "motor_led", you have a sub-folder called "adavance one timer" where you have the same function but done in a another way. Be careful to use all files from the same sub-folder.

Kind regards


Le 02.12.2011 12:32, Duarte Dias a écrit :
Hi Michael,

Thx so mutch for the reply. I took the "shadow" option from the motor timers and it really helped. At least the program is starting to provide accurate results. The program still crashes doght once in a while. I'm using a timer to check for new motor commands and to save odometry measurments. This timer is set up to 100ms. If I lower the time (say 10ms) the program starts to crash more. What could be the problem? Perhaps the interrupt is taking too mutch time to be executed? How can I see that?

Also what is the "advance one timer" ?

Again thank you for the help!

Duarte Dias

2011/11/30 Michael Bonani <michael.bon...@epfl.ch <mailto:michael.bon...@epfl.ch>>

    There is probably problems with the priority of the interrupts. If
    you use the normal library (that you modifiy for using timer 2 and
    3) for the motor it will not work. Use the "advance one timer", it
    should be better. You can also try to remove the "shadow" option
    of all iterrups that are not for the camera, should also works.
    If not send the all code.

    Michael Bonani

    Le 30.11.2011 15:13, Duarte Dias a écrit :

    I have an e-puck program that captures images (timers 4,5), moves
    the robot (timers 2,3), periodically generates odometry
    measurments (timer 1), process captured image and sends a small
    buffer with results (48 bytes) to bluetooth after the capture is
    done (I do not wait for the transmission to be complete).
    The odometry measurments are processed while the capture is being
    done (while we wait for the end of the capture).

    All works well speratly (just capture, only movement with
    odometry, etc), but when I plug all of this together in the main
    loop, the e-puck starts to crash and the funxtions generating
    silly data. Since the functions do not generate silly data when
    capture is off, I assume that the problem is when I plug the
    capture, and not in the functions.

    Does the camera has some problems with capture, while doing more
    stuff in between the capture, ex. moving (other timer events),
    performing operations (while wating for the end of the capture),

    If not the camera, what could be the problem?

    Duarte Dias

    E-puck-user mailing list
    E-puck-user@gna.org  <mailto:E-puck-user@gna.org>

E-puck-user mailing list

Reply via email to