Subject:
|
Re: Robolab, byte codes and assembler
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Fri, 28 Nov 2003 22:33:02 GMT
|
Viewed:
|
10276 times
|
| |
|
|
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.
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.
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.
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., 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. Or your robot could drop
something at its starting location to serve as a positioning beacon to help it
return to home base. 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.
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.
Just my thoughts; do with them as you will. Good luck!
- Chris.
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | 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)
|
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
|
|
|
|
