Subject:
|
Re: Interesting BrickOS Timing Results
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 15 Jan 2003 05:15:10 GMT
|
Viewed:
|
3126 times
|
| |
|
|
I did some "real world" tests with this update. I was Astounded at what
a difference it makes. The bot I was testing with is a killough
platform; which I had tried for hours previously, to get it to follow a
line smoothly. I think BrickOS was giving too little processing time to
the tasks, because it would jerk back and forth and often miss the line.
I tried rebuilding the bot, lowering the gear ratio, raising and
lowering the light sensor (which helped a bit) and various programming
techniques. I was able to get it to work, about half the time, but it
wasn't very satisfying.
Now, thanks to Mark, Dick and everyone else that posted, this bot works
quite well. With no changes to the program or bot, No more swinging
right past the line. As with any line follower (pretty much) there is
some "swinging" back and forth, but it is much quicker to respond to the
edge of the line.
Now, what to do... what is the best solution to this issue? If no one
else solves it first... I will try to dedicate some time this next
couple of weeks.
// Joe
Joseph Woolley wrote:
> Mark,
>
> I retrieved the latest BrickOS from CVS, made clean and made the cpu
> test program you listed.
>
> I then made two small changes (to see what would happen); first the
> results, then the changes:
>
> IDLE: 89
> 2ROT: 87
> NOAD: 91 (see below)
> NIRQ: 98 (see below)
>
> Ok, this looks promising, here is what I did. This is the most simple
> change I could think of on short notice 8-)
>
> I commented out the line:
> bset #0x5,@_AD_CSR:8 ; go!
> at the end of the ds_handler; so now the A/D convertion doesn't start up
> again (yet)
>
> Then I added the same line to the end of the systime_handler. This
> starts the A/D conversion every 1 msec.
>
> OK, so this is not the end-all solution, but it is a good start IMO. The
> interval should be user selectable (maybe) at run-time. However, the
> numbers are much higher with this simple change. I would love to test
> it with the rotation sensor at various speeds (motor x 1, motor x 2, x
> 3, etc..) to see how it performs in comparison with the original
> method. However, I don't have time right now.
>
> // Joe
>
>
> Mark Riley wrote:
>
> > Oops, found a little bug. ;-) Forgot to turn off the rotation
> > sensors. Caused a wrong reading if you let the program
> > run through the readings more than once. The rotation
> > sensor section should read like this:
> >
> > // with two rotation sensors enabled (23%)
> > cputs("2rot"); msleep(100);
> > ds_rotation_on(&SENSOR_1);
> > ds_rotation_on(&SENSOR_2);
> > cpu();
> > ds_rotation_off(&SENSOR_1);
> > ds_rotation_off(&SENSOR_2);
> > sleep(3);
> >
> > Mark
> >
> >
> >
>
|
|
Message is in Reply To:
 | | Re: Interesting BrickOS Timing Results
|
| Mark, I retrieved the latest BrickOS from CVS, made clean and made the cpu test program you listed. I then made two small changes (to see what would happen); first the results, then the changes: IDLE: 89 2ROT: 87 NOAD: 91 (see below) NIRQ: 98 (see (...) (22 years ago, 15-Jan-03, to lugnet.robotics.rcx.legos)
|
19 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
