 | | 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
|
|
(...) 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
|
|
---...--->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
|
|
(...) 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
|
|
(...) 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
|
|
Thanks for the response. (...) It seems to me it's a design flaw in the entire method of counting rotations, which relies on the theoretical ideal of "instantaneous" voltage changes, which can't be produced. You can't go from 2V to 5V without (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
| |
| | Re: Robolab, byte codes and assembler
|
|
(...) Yes, I did read your information. It was very helpful - the best stuff I found on the subject. But as you said, modifying the sensor would probably disqualify. But, that does make me think again about the recent unavailability of the part . . (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
| |
| | Re: multiple motors
|
|
(...) Rather well... (...) ...but it was beaten by a simpler but slightly heavier 'bot! And it sometimes committed suicide too :-(( Philo (21 years ago, 27-Nov-03, to lugnet.robotics.rcx)
|
| |
| | Re: Robolab, byte codes and assembler
|
|
"Don Stauffer" <BrainChild@Skyler.com> wrote in message news:Hoz4Gp.1zto@lugnet.com... (...) <<SNIP>> (...) The rotation sensor bad counts cannot be fixed at the byte-code level. The problem is "native" to implementation in the underlying firmware (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
| |
| | Re: Robolab, byte codes and assembler
|
|
Hello Don, Did you had a look to my analysis of this problem ((URL) But unfortunately I don't think that my modification is "competition-legal"... I agree that sampling can occur at the wrong time, but this should not occur more often at low (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
|
