 | | 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 (...) (22 years ago, 28-Nov-03, to lugnet.robotics.rcx.robolab)
|
| |
| | 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 (...) (22 years ago, 28-Nov-03, to lugnet.robotics.rcx.robolab)
|
| |
| | 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 (...) (22 years ago, 28-Nov-03, to lugnet.robotics.rcx.robolab)
|
| |
| | 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 (...) (22 years ago, 28-Nov-03, to lugnet.robotics.rcx.robolab)
|
| |
| | Re: Robolab, byte codes and assembler
|
|
(...) It really is. I do think somebody made a mistake specific to the rotation sensor, though. I haven't decided yet whether it's the firmware, the sensor, or just the overall mechanism. I can understand how it got past quality control - sometimes (...) (22 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
