Subject:
|
Re: Robolab, byte codes and assembler
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Thu, 27 Nov 2003 22:56:55 GMT
|
Viewed:
|
9646 times
|
| |
|
|
In lugnet.robotics.rcx.robolab, Claude Baumann wrote:
> --------------->snip
> > That may be another problem to be solved; haven't got there yet because simply
> > counting rotations has been unreliable. I mean with a motor shaft connected to
> > a rotation sensor - no wheels, no robot! Can't even count rotations correctly.
>
> Welcome to LEGO Mindstorms robotics: do great things in real world with
> imperfect tools and objects. That's what makes it so interesting. It's always
> the Apollo 13 challenge: "Here guys, that's what they have on bord! Come on and
> solve that problem!"
Unfortunately, I fear the comparison is all too true!
So, is my robot going to blow up? ;)
> In ROBOLAB you can easily study the error your sensor is currently producing
> with your robot design, under your specific conditions. Do not forget to analyze
> at different battery-charges. I would gather statistical data, then correct the
> errors in the ROBOLAB-code.
I'd appreciate some specifics. So far, I have not been able to find a way to do
this in Robolab. I wrote some code to test raw sensor values and update a
counter, the same way presumably the firmware keeps count, except I take two
samples and average them. It seems like the Robolab code must take too much
time to evaluate all this compared to the interrupt routines, because it makes
the problem worse rather than better, though probably for a different reason:
I'm just completely missing some transitions while processing previous ones.
I can imagine another strategy: timing between the transitions and interpolating
when one may have been missed. But that would probably suffer from the same
problem, plus it would be inaccurate when the speed changes.
If you're talking something like: "average dropped counts = one per 30
rotations, so multiply distance calculated by 1.002", that would only work if
either the dropped counts predictably occurred at regular intervals (they don't)
or the number of rotations were sufficient that the variability of the error
could be averaged (it's not). The result of this kind of estimate under these
conditions would be to ensure the distance calculated was _never_ correct,
instead of _usually_ correct as it is now.
> Standard ROBOLAB allows all this and should be
> largely sufficient for most competition at school level.
"Sufficient" implies an issue of degree; I consider this an issue of "doesn't
work".
> As to directly accessing ROM or firmware functions from ROBOLAB, alter or
> replace them, I'm very sceptic here. In its first handler
> the standard firmware
> reads and updates boolean, percent, temperature, angle sensor-values. Depending
> on what other handlers have to do this is not exactly done at the same rate.
I find this description vague. Can you clarify? In my experience (not RCX),
device routines each handle one device, but you imply multiple "handlers", all
dealing with potentially the same multiple devices. Why would more than one
handler have to read/update the same sensors? And why does it matter if it's
done at the same "rate" - the same rate meaning what? Update time in each
handler? Time between executions of the handler? Something else? Why does
this matter?
Or by "handler" are you referring to the "controller" (hardware itself)?
The
> A/D interrupt handler does not intervene directly here. Let's have closer look:
This is unclear. Code doesn't "intervene"; it gets executed.
> 1. the OCIA-handler is executed at interrupt every ms. Every 3 ms the sensor
> output-pins on port6 are set to 0 and the A/D interrupt is enabled.
What is OCIA?
> 2. At A/D interrupt a flag is set for the first firmware-handler to allow its
> execution. The sensor output-pins on port6 are set to the selected value (0 or
> 1, depending on the sensor type and mode)
> 3.the firmware checks which handler has to be excuted. If the first handler is
> executed -at minimum interval 3ms, which rarely seems possible, since all the
> other handlers have to be executed too- the non-raw sensor values are updated,
> for instance the rotations are incremented or decremented.
>
> ---> with the standard firmware you can't do it faster, even if you changed some
> code.
Why does that matter? The dropped counts are not caused by the shaft turning so
fast the handler misses them, they're caused by voltage transitions being
ignored because samples are occurring during the transition, when the voltage
matches the value _two_ ticks before or after the starting value. IOW, a design
flaw.
|
|
Message is in Reply To:
 | | Re: Robolab, byte codes and assembler
|
| ---...--->snip (...) Welcome to LEGO Mindstorms robotics: do great things in real world with imperfect tools and objects. That's what makes it so interesting. It's always the Apollo 13 challenge: "Here guys, that's what they have on bord! Come on (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
24 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
