| | Re: Robolab, byte codes and assembler
|
|
(...) I tend to think that positionning errors are more a problem of slip/skid than a problem of lost counts... Philo (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
|
| | Re: Robolab, byte codes and assembler
|
|
(...) That may be another problem to be solved; haven't got there yet because simply counting rotations has been unreliable. I mean with a motor shaft connected to a rotation sensor - no wheels, no robot! Can't even count rotations correctly. (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
|
| | Re: Robolab, byte codes and assembler
|
|
---...--->snip (...) Welcome to LEGO Mindstorms robotics: do great things in real world with imperfect tools and objects. That's what makes it so interesting. It's always the Apollo 13 challenge: "Here guys, that's what they have on bord! Come on (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
|
| | Re: Robolab, byte codes and assembler
|
|
(...) By contrast, BrickOS continuously samples each sensor at a rate of about 6.7 samples per millisecond. This is 20 times more often than the standard firmware. It's no wonder it's more accurate at higher rotation rates. Of course, it also (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
|
| | Re: Robolab, byte codes and assembler
|
|
(...) We should not forget that the RCX has initially been designed for kids. So the standard firmware should be considered according to the initial aims, which were to provide a really great tool - toy for children. Therefore the firmware designers (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
|
| | Re: Robolab, byte codes and assembler
|
|
(...) Please don't take my post as a criticism of the original firmware, I merely wanted to point out alternatives. I agree, the 3ms sample rate is more than adequate for most applications. (...) Yes, the RCX is rugged in many respects, but I think (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
|
| | Re: Robolab, byte codes and assembler
|
|
OK You do something great, and all the world is looking at it, finding the finest detail one could have made much better. That's the power of internet-exchange. Don't take this personally. I only wanted to remind the great job they did at LEGO's (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
|
| | Re: Robolab, byte codes and assembler
|
|
(...) Unfortunately, I fear the comparison is all too true! So, is my robot going to blow up? ;) (...) I'd appreciate some specifics. So far, I have not been able to find a way to do this in Robolab. I wrote some code to test raw sensor values and (...) (21 years ago, 27-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 (...) (21 years ago, 27-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 (...) (21 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 (...) (21 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 (...) (21 years ago, 28-Nov-03, to lugnet.robotics.rcx.robolab)
|
|
| | 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)
|
|
| | 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)
|
|
| | 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)
|