Subject:
|
Re: Robolab, byte codes and assembler
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Fri, 28 Nov 2003 20:44:45 GMT
|
Viewed:
|
10312 times
|
| |
|
|
In lugnet.robotics.rcx.robolab, Claude Baumann wrote:
<snip>
> > 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 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 also, so precise maneuvering may be required to
find them.
> 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.
My point was, if you travel a distance which requires 30 rotations, which is
about the average before one dropped count in my experience, you have a choice
of either assuming there is a dropped count and waiting for only 29 15/16
rotations, or ignoring any error. Either way, you'll be wrong by 1/16 rotation
half the time. If you need to travel a distance which requires 15 rotations,
you could say "I lose one count every 30 rotations, so my adjustment is the
distance traveled in 1/32 rotation", you'd be 1/32 rotation off whether the drop
happens or not (not that you can measure 1/32 rotation, but with rounding it
might actually put you off a whole 16th).
The unpredictability of whether you will or won't lose one count in attempting
to travel typical distances expected in this type of event means the best you
could do is make the adjustment if the distance is greater than the average
which produces a drop, and don't make it for shorter distances. Since the drops
vary extremely widely in how often they occur, this would be lots of work for
almost no gain. The distance would pretty much be just as inaccurate due to the
extreme randomness of the drops.
> 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.
Yes, that was my conclusion also.
> 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.
Already done. See above.
> 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.
OK. They change resources also used by other tasks, which affects the 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
Remarkably similar to what I attempted in Robolab. Is there information on the
procedure one would use to insert patch code in existing firmware? Presumably
the idea would be to modify the firmware file on the PC, then re-install the
firmware to the RCX. Do you know where I can find the format of that file?
Presumably no source code is available for the robolab firmware, so I expect it
would be an interesting exercise in analyzing and modifying the binary!
Fortunately the needed changes are fairly minimal.
> 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?)
No. Sensors must be in "original factory condition". In my tests, the low
speed problem seemed more severe, so I think it would prevent using an
unmodified sensor to control steering, for example.
|
|
Message has 1 Reply:
 | | Re: Robolab, byte codes and assembler
|
| (...) All this talk of patching firmware to correct for problems in rotation sensor readings is very interesting, but I think you may be approaching the problem a bit too directly. First, if the competition rules specify the programming environments (...) (21 years ago, 28-Nov-03, to lugnet.robotics.rcx.robolab)
|
Message is in Reply To:
| | Re: Robolab, byte codes and assembler
|
| ---...--->snip (...) 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 (...) (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
|
|
|
|
