Subject:
|
Re: Robolab, byte codes and assembler
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Thu, 27 Nov 2003 17:34:17 GMT
|
Viewed:
|
9791 times
|
| |
|
|
--------------->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!"
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. Standard ROBOLAB allows all this and should be
largely sufficient for most competition at school level.
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. The
A/D interrupt handler does not intervene directly here. Let's have closer look:
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.
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.
|
|
Message has 2 Replies:
 | | Re: Robolab, byte codes and assembler
|
| (...) By contrast, BrickOS continuously samples each sensor at a rate of about 6.7 samples per millisecond. This is 20 times more often than the standard firmware. It's no wonder it's more accurate at higher rotation rates. Of course, it also (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
| | | Re: Robolab, byte codes and assembler
|
| (...) Unfortunately, I fear the comparison is all too true! So, is my robot going to blow up? ;) (...) 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 (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
Message is in Reply To:
| | Re: Robolab, byte codes and assembler
|
| (...) 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. (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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
