Subject:
|
Re: Robolab, byte codes and assembler
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Fri, 28 Nov 2003 11:08:54 GMT
|
Viewed:
|
10008 times
|
| |
|
|
---------------------->snip
> I'm quite interested in the alternative firmware for myself. However, for this
> particular problem, if a correct rotation count is my "Apollo 13's needed
> filter", then Robolab is the "cover of the flight manual" - it's what I have on
> board, so I have to use it. FIRST sets the competition rules (of course they
> _might_ change next year for all I know . . .)
I guess the competition asks you to run a certain distance as precisely as
possible, or/and do some precise turns. We often experienced this kind of
challenges in our school. The best way seemed to be to collect statistical
information about the involved sensor. Unpredictable events such as count drops
can be analyzed with repeated tests. So you get a standard deviation of your
data. As to statistics, you need a sufficient number of tests of course. Done
this you should be able to have a better view than NEVER_CORRECT or something
like that.
If you are testing the rotation-sensor at raw-values with ROBOLAB, you're result
is rapidely aliased depending on your motor speed. The sensor counts are done at
firmware level at a periode of about 3ms. If you do it through a (ROBOLAB byte
code orientated program) your sampling-rate is significantly slower.
So I'd do these tests more pragmatically. Take your motor, add the rotation
sensor and a control sensor like a touch-sensor counting clicks. Then operate
several experiments with a larger number of rotations at different speeds. Now
analyze your data.
To the handler: the firmware executes different handlers doing various jobs:
multitasking-scheduler, IR- RX/TX, motor-control, sensor-control,
display-update, sound and so on. The firmware works like a state machine. It
gathers information about the RCX's states and executes the handlers
accordingly. (A handler is part of the code which is related to a specific
state.)
Don' forget the RCX is a multitasking machine. So, things which are done in one
task, can affect ("intervene into") other tasks.
OCIA- is the H8-designation for the Output Compare Interrupt Request (register
A). The 16-bit free-running hardware-timer of the H8-microcontroller is
configured to produce an interrupt each ms. At interrupt, the normal process is
stopped, some context data is saved to the stack (program-counter,
status-register, registers), the program-counter is set to the interrupt-vector
(here OCIA-handler address), then the OCIA-handler is executed, the context
restored and returned to the normal process.
The transition-problem at high motor speed is a time-problem. Here an extract of
Kekoa's ROM-hack data. This code is only executed from the first firmware
handler, when the firmware is sure a new sensor-sampling has been executed.
During the transition from state3 to state0 or vice-versa, there is a
probability that the sensor reads intermediate values, as Philo points out.
Increasing the sampling rate and slightly changing the software returns a better
result as brickOS demonstrates.
....
case e0: // angle
sensor->boolean = boolean
if (raw < 1bf)
state = 0
else if (raw < 2bf)
state = 1
else if (raw < 3bf)
state = 2
else
state = 3
if (angle previous state[index] (byte @ef32[index]) == 0)
if (state == 1)
sensor->value++
else if (state == 2)
sensor->value--
else if (angle previous state[index] (byte @ef32[index]) == 1)
if (state == 3)
sensor->value++
else if (state == 0)
sensor->value--
else if (angle previous state[index] (byte @ef32[index]) == 2)
if (state == 0)
sensor->value++
else if (state == 3)
sensor->value--
else if (angle previous state[index] (byte @ef32[index]) == 3)
if (state == 2)
sensor->value++
else if (state == 1)
sensor->value--
angle previous state[index] (byte @ef32[index]) = state
endswitch
As to the drops at low speed. Philo solved the problem through adding a
capacitor. That's the best solution since you can still continue programming
with the standard firmware. (Is this compatible with the competition rules?)
|
|
Message has 1 Reply:
 | | Re: Robolab, byte codes and assembler
|
| In lugnet.robotics.rcx.robolab, Claude Baumann wrote: <snip> (...) The main need is to return to the starting point after completing various challenges. I think the challenges also involve objects at known positions compared to the starting point (...) (21 years ago, 28-Nov-03, to lugnet.robotics.rcx.robolab)
|
Message is in Reply To:
| | Re: Robolab, byte codes and assembler
|
| (...) <snip> (...) I'm quite interested in the alternative firmware for myself. However, for this particular problem, if a correct rotation count is my "Apollo 13's needed filter", then Robolab is the "cover of the flight manual" - it's what I have (...) (21 years ago, 28-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
|
|
|
|
