Subject:
|
Re: Robolab, byte codes and assembler
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Sat, 29 Nov 2003 18:05:43 GMT
|
Viewed:
|
10267 times
|
| |
|
|
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.
> 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.
> 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. 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.
> 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.
?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.
> 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?
> 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.
> 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.
|
|
Message has 1 Reply:
 | | Re: Robolab, byte codes and assembler
|
| (...) 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 (...) (21 years ago, 29-Nov-03, to lugnet.robotics.rcx.robolab)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
