Subject:
|
Re: Robolab, byte codes and assembler
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Sat, 29 Nov 2003 20:29:32 GMT
|
Viewed:
|
10719 times
|
| |
|
|
In lugnet.robotics.rcx.robolab, Don Stauffer wrote:
> In lugnet.robotics.rcx.robolab, Chris Phillips wrote:
> > In lugnet.robotics.rcx.robolab, Don Stauffer wrote:
> > > 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.
> >
> > 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 that are
> > allowed, they will almost certainly not allow patched firmware. Otherwise, you
> > could (for example) patch the firmware with an algorithm that does all the hard
> > work for you and then simply call that routine from RoboLab or RIS. This would
> > defeat the purpose of having everyone use the same programming tools, and would
> > probably be outside the spirit of the rules. Besides, if you are competing
> > against others who have the same firmware, then you aren't really at a
> > disadvantage because of the rotation sensor inaccuracy. Everyone will be
> > susceptible to the same odometry errors.
>
> My arguments would be: 1. The firmware/sensor arrangement is _broken_. Fixing
> it should be legal. 2. The FIRST rules permit using different firmware
> implicitly, because they permit using RIS or Robolab, which requires different
> firmware. 3. The logical extreme of what you suggest is that writing a Sub vi
> in Robolab should be illegal. You could just "call an icon that does all the
> work". Except, "calling an icon [subroutine] that does all the work" is a
> legitimate, _desirable_ programming technique. It's appropriate that it be
> taught.
Should be legal, perhaps. But I was just suggesting that before sending him off
to try to patch the firmware, he might want to make sure it was legal to do so.
Although RIS and RoboLab may not use the same identical firmware, that doesn't
necessarily mean that any firmware goes. Clearly, the FIRST rules are designed
to provide a level playing field for all contestants, so it is more than likely
that they would not allow patched firmware for any reason.
If it was simply about solving the problem by any means then they would allow
the use of any programming environment, including NQC and BrickOS. Clearly
there would be great educational value in either of these choices as well.
> > Second, patching the firmware as you describe is a pretty hefty job. You'd have
> > to disassemble the firmware, reverse-engineer it, and then repair it without
> > introducing any new bugs. This assumes that it is even possible to correct the
> > rotation sensor problem at the firmware level.
>
> Difficult in concept, but this is a relatively small memory footprint and a
> relatively small amount of processing. Once done, it works for whatever you
> want to use it for - steering, distance, something else. People have completely
> rewritten the firmware from scratch.
You've shown that this is probably a do-able job in much less time than I would
have expected, and I applaud your efforts to provide a patch for FIRM0328.LGO.
I know a lot of people (myself included) will be very grateful to you if you are
successful in doing this.
But as someone who has frozen at least one RCX trying to write my own
replacement firmware, I was trying to point out that this is not for the faint
of heart.
Also, my understanding of the problem is that at certain transition points, the
sensor provides ambiguous readings, so this may not be a problem that can be
completely solved with any amount of software. If you are ultimately forced to
accept that the sensor will produce errors, you'll have to work around them at
some level anyway.
> > Third, not to be critical, but isn't the FIRST competition held between school
> > children? If your child is capable of disassembling, reverse-engineering, and
> > patching the firmware, well Ok, but if you are going to do it for him/her,
> > aren't you kind of getting a bit more involved in this project than you should
> > be? I think the child learns more by doing and failing than by having a winning
> > solution handed to them by someone else.
>
> I'm concerned about this, and perhaps it should be checked into. Again, my
> feeling is that this tool is broken, and fixing it before giving it to kids is
> only reasonable. Others may disagree, and I don't know what the officials would
> say.
I agree with you as well, but the only relevant point in this competition is
what the officials would say.
> This is why I was looking for a less "invasive" solution, one which maybe
> used LASM code in Robolab. The only other alternative I can think of is
> ditching rotations sensors entirely and using light sensors. Since FIRST only
> permits two light sensors on the robot, I consider this a last resort in case
> some challenge requires or could use two light sensors. Another "oddball"
> alternative would be somehow rotating a light sensor into one of two different
> positions depending on whether you want to track rotations or do something else.
> That could get really messy, but it could work.
If I understand it correctly, LASM is really nothing more than a different way
to specify bytecode programming, not unlike what NQC does. The bytecode
operands are very carefully "sandboxed" to prevent the kind of low-level
programming that can hang the RCX, and therefore it lacks the level of control
required to circumvent the bug. Since the rotation sensor code is in the
firmware interpreter, I am afraid that no amount of bytecode programming is
going to fix it.
> > You might do better to think outside the box, to borrow a tired expression.
> > Either gear your robot so that a few lost counts is insignificant relative to
> > gear lash, etc.,
>
> OK up to the point where the rotation speed exceeds the 500 RPM the rotation
> sensor is rated to handle. Then you start getting "conventional" dropped
> counts, where the shaft turns too far between samples. Actually, I think those
> would be _double_ drops.
Right, it's a matter of gearing the rotation sensor so that it operates solidly
in the middle of its reliable operating range.
> > or find another way to measure distance or return to your
> > starting location. You could create your own rotation sensor using a touch or
> > light sensor that counts pulses from a rotating wheel.
>
> Again, this idea occurred to me. The disadvantages are: typical solutions
> require more inputs and/or outputs; typical solutions suffer from the
> "conventional drops" mentioned above and are actually _less_ accurate than a
> rotation sensor with drops; and typical solutions use up one or more of the
> limited number of sensors in FIRST.
I've read about people designing rotation sensors that use a single touch or
light sensor, so I think it could be done using the same number of inputs used
by the rotation sensor. You are correct that these approaches may very well be
less accurate than the rotation sensor, which brings me back to the question of
whether the small errors caused by the bug are bad enough that they need to be
fixed in order to win.
> > Or your robot could drop
> > something at its starting location to serve as a positioning beacon to help it
> > return to home base.
>
> Not sure I get this one. How would the "beacon" be located by the robot?
Any number of "beacons" or "home bases" could be employed. This could be as
simple as a frame that the robot drops at its starting location, and which it
drives back into when it gets back to its approximate starting location using
imprecise odometry. Some have created beacons that use a battery box and a
motor to flash a light at a certain frequency that can be located using a light
sensor on the robot. Or it could just be a column of a certain color and width
that the robot detects using infrared "radar" or a conventional light sensor.
But this is also something to check the FIRST rules on before spending a lot of
time to implement.
> > Or you could create a mechanism that uses a string on a
> > spool to only allow it to back up as far as it moved forward in the first place.
>
> I also considered this; it could work, but would not be reliable in that the
> string could get caught, tangled, etc. Also wouldn't tell you how far you went
> in a given direction; turns would foul it up, and it would only be good for the
> "return to base" issue.
The string doesn't need to be trailed out from the starting location, but could
simply be moved from one spool to another inside the robot. If the mechanism is
designed to only allow the robot to back up as far as it has already moved
forward, this could be used as one way to return to home base without using any
sensor inputs whatsoever.
Of course, if the robot must maneuver within an X-Y plane, this becomes more
complicated, but still do-able. I forget the name, but there is a platform
design that is capable of moving in both the X and Y directions without
rotating/turning the robot chassis.
> > These are off-the-cuff thoughts, but might give you some ideas for other ways to
> > approach the problem.
> >
> > I've made the mistake of trying to tackle a problem using the first approach
> > that occurred to me, wasting huge amounts of effort trying to overcome
> > insurmountable problems, only to be beaten by someone who used an entirely
> > different, simpler solution. I think you might want to step back and consider
> > whether there are other ways to solve this challenge that might be more in
> > keeping with the spirit of the competition.
>
> Extremely good point. A good thing to keep reminding oneself. Periodically
> back off and try a different approach.
>
> > Just my thoughts; do with them as you will. Good luck!
> >
> > - Chris.
>
> Much appreciated.
I very much appreciate your efforts to patch the firmware to correct for the
rotation sensor bug. If you are successful, many people will benefit from this.
I was mainly trying to point out that it is easy to become so focused on one
solution to a problem that you forget to consider other alternatives. Or so
fixated on solving one perceived problem that you overlook its overall
insignificance. It would be a shame to be disqualified for using modified
firmware if it turns out to be a relatively unimportant source of navigational
errors.
I've used odometry quite a bit in my robot designs, and it works quite well
within limits. Perhaps it is accurate enough to win the FIRST League
competition without worrying too much about a few dropped counts? In any case,
you are likely to drop roughly the same number of counts on the way home as you
do on the way out, so even using statistical techniques to try to predict
odometry errors may prove to be unnecessary.
- Chris.
|
|
Message is in Reply To:
 | | Re: Robolab, byte codes and assembler
|
| (...) My arguments would be: 1. The firmware/sensor arrangement is _broken_. Fixing it should be legal. 2. The FIRST rules permit using different firmware implicitly, because they permit using RIS or Robolab, which requires different firmware. 3. (...) (21 years ago, 29-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
|
|
|
|
