Hi,
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
Michael
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!
Regards,
Duarte Dias
2011/11/30 Michael Bonani michael.bon...@epfl.ch
mailto:michael.bon...@epfl.ch
Hi,
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.
Regards
Michael Bonani
Le 30.11.2011 15:13, Duarte Dias a écrit :
Hi,
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),
etc.?
If not the camera, what could be the problem?
Regards,
Duarte Dias
___
E-puck-user mailing list
E-puck-user@gna.org mailto:E-puck-user@gna.org
https://mail.gna.org/listinfo/e-puck-user
___
E-puck-user mailing list
E-puck-user@gna.org
https://mail.gna.org/listinfo/e-puck-user
