 | | Re: What I would do (2) —Alexander Sack
|
| | | (...) After talking with another fellow Lugnet guy, I would be up for any of the following (btw, I have no idea what is available for the NXT beta so some of this stuff maybe completely redundant): - developing a complete SDK for NXT - (...) (19 years ago, 17-Jan-06, to lugnet.robotics)
|
| | | |
| | | | | Re: What I would do (2) —Ram Meenakshisundaram
|
| | | | | Count me in as well. I am planning on doing more development environments especially AI & Parallel Processing based. Occam-2, Prolog, and LISP/SCHEME are on my list. I also want to create new sensors including an I2C-bridge (if it is not already (...) (19 years ago, 17-Jan-06, to lugnet.robotics)
|
| | | | | |
| | | | | Re: What I would do (2) —Steve Hassenplug
|
| | | | (...) What is RTOS, uCOS, and Redboot/eCOS? Steve (19 years ago, 17-Jan-06, to lugnet.robotics)
|
| | | | |
| | | | | | Re: What I would do (2) —Alexander Sack
|
| | | | (...) RTOS - Real-time Operating System uCOS-II (MicroCos-II) which is a RTOS implementation that has been ported to many platforms including the ARM7 (URL) - Redboot is a generic bootloader for embedded systems and eCOS is a RTOS. Both are projects (...) (19 years ago, 17-Jan-06, to lugnet.robotics)
|
| | | | |
| | | | | | Re: What I would do (2) —Ed Manlove
|
| | | | (...) Hitachi processor to an 32 bit ARM7 processor, one would need to rewrite brickOS kernel for the ARM7 processor. But why reinvent the wheel when there is already several really good real-time operating systems for the ARM, including uCOS-II? I (...) (19 years ago, 26-Jan-06, to lugnet.robotics)
|
| | | | |
| | | | | | Re: What I would do (2) —Alexander Sack
|
| | | | (...) If the mechnisms for control are still applicable, then yeah, you could port over the code that is used to activate the various sensors. In terms of uCOS, after reading half of the kernel book and actually working with it a little bit (the (...) (19 years ago, 26-Jan-06, to lugnet.robotics)
|
| | | | |
| | | | | | Re: What I would do (2) —Ed Manlove
|
| | | | (...) Alexander, What you are describing seems more like an end application (multiple autonomous robots that do X and Y and can communicate using Bluetooth) then an RTOS design. An analogy of your description of using the NXT processor for just the (...) (19 years ago, 26-Jan-06, to lugnet.robotics)
|
| | | | |
| | | | | | Re: What I would do (2) —Tim Byrne
|
| | | | | (...) I would be in favor of having a port of BrickOS for NXT (instead of having another thing to learn). I'm not gonna throw away my RCXs and I would prefer having similar languages for both bricks. Yes programmers would need to know the nuances (...) (19 years ago, 26-Jan-06, to lugnet.robotics)
|
| | | | | |
| | | | | | | Re: What I would do (2) —Ed Manlove
|
| | | | | | | (...) Very good point! So one design goal/guiding principle would be try not to break brickOS programs for NXT and provide if nessecary a easy software upgrade path. (...) I would really like to point out (to the general audience) what I see as a (...) (19 years ago, 27-Jan-06, to lugnet.robotics)
|
| | | | | | | |
| | | | | | | | | Re: What I would do (2) —Tim Byrne
|
| | | | | | | | | (...) I'll add it to my tool belt if it'll run on Linux ;) I certainly don't mean to slight the NXT software (I haven't even played with it yet). I assume it will be quite capable. (...) Indeed. Programming languages are simply tools. They should be (...) (19 years ago, 27-Jan-06, to lugnet.robotics)
|
| | | | | | | | | |
| | | | | | | | | Re: What I would do (2) —John Hansen
|
| | | | | | | | (...) <snippage> (...) Ed, can you point me to the sort of things you have read which make you believe the NXT software and its underlying firmware will provide the sort of control and flexibility which such things as NQC and alternate firmwares (...) (19 years ago, 31-Jan-06, to lugnet.robotics)
|
| | | | | | | | |
| | | | | | | Re: What I would do (2) —John Hansen
|
| | | | | | (...) I like this concept, but what if in the case of NQC the new firmware turns out to be such a radically different design that it makes it extremely difficult, if not impossible, to carry over very much of the rather large API built into NQC to (...) (19 years ago, 31-Jan-06, to lugnet.robotics)
|
| | | | | | |
| | | | | | | | Re: What I would do (2) —Philippe Hurbain
|
| | | | | | | (...) As the brick, sensor, motors... are quite different, direct portability is not of paramount importance for me. So I vote for performance. Philo (19 years ago, 31-Jan-06, to lugnet.robotics)
|
| | | | | | | |
| | | | | | | | Re: What I would do (2) —Ross Crawford
|
| | | | | | | (...) The optimum solution would be both - provide a new API that gets the most out of the new firmware, but an optional "compatability layer" that adds what is necessary to provide an API compatable with the RCX. Note that I'd vote to get the new (...) (19 years ago, 31-Jan-06, to lugnet.robotics)
|
| | | | | | | |
| | | | | | | | Re: What I would do (2) —John Barnes
|
| | | | | | | (...) Oh, performance! NXT NQC should match the NXT brick's capabilities. How many people have such sophisticated programs that they need to port from the RCX to the NXT to realisically demand compatibility? I mean this a robot hobby tool. Half the (...) (19 years ago, 31-Jan-06, to lugnet.robotics)
|
| | | | | | | |
| | | | | | | | Re: What I would do (2) —David Schilling
|
| | | | | | | (...) Definitely performance! Trying to porting an old RCX program to the NXT would be near impossible -- everything is so different there. Just as you'd have to totally rebuild your robot, you have to do a total rewrite of your code anyway. So (...) (19 years ago, 1-Feb-06, to lugnet.robotics)
|
| | | | | | | |
| | | | | | | | | Re: What I would do (2) —Tim Byrne
|
| | | | | | | | (...) Absolutely. I think the design of the NXT NQC should be dependent on the standard firmware just as NQC was based on the RCX firmware. David nailed exactly what I'm interested in. Even when using NQC it still **feels** like I'm writing in C. It (...) (19 years ago, 1-Feb-06, to lugnet.robotics)
|
| | | | | | | | |
| | | | | | | | Re: What I would do (2) —Andrew Cross
|
| | | | | | | (...) Performance should come first. But thinking about API compatability, hopefully we will get a more programmable environment than the RCX's limitation from registers, functions and memory. A slowdown process may also be needed to make the NXT (...) (19 years ago, 1-Feb-06, to lugnet.robotics)
|
| | | | | | | |
| | | | | | | | Re: What I would do (2) —Anders Isaksson
|
| | | | | | (...) I'd say: Go for the NXT thing! Give us a language that utilizes the NXT as much as possible. As the NXT is both faster and has more memory than RCX (not to mention the CyberMaster, which is all I have for the moment) it doesn't seem (...) (19 years ago, 1-Feb-06, to lugnet.robotics)
|
| | | | | | |
| | | | | | Re: What I would do (2) —Alexander Sack
|
| | | | (...) power) and has 64k of memory. How much runtime state can you really process with 64k after the kernel and sensor/motor processes are loaded? Maybe more than I think... Btw, thanks for the document! The current paradigm in RTOS design seems to (...) (19 years ago, 27-Jan-06, to lugnet.robotics)
|
| | | | |
| | | | | | Re: What I would do (2) —Ed Manlove
|
| | | | (...) The processor speed (even underclocked) will not be an issue. There real issue which I see many people have talked about is the amount of memory will be in the NXT. On the website for uCOS-II there is a RAM calculation (for the Intel 80x86 (...) (19 years ago, 27-Jan-06, to lugnet.robotics)
|
| | | | |
| | | | | | Re: What I would do (2) —Alexander Sack
|
| | | | (...) Didn't say it was! :-)! (...) Bingo! (...) I'm running it now and its quite a nice little OS. Like we both said, the real work is just asking tasks to manage the specific resources of the NXT. (...) Again, totally agree (as I stated in my last (...) (19 years ago, 27-Jan-06, to lugnet.robotics)
|
| | | | |
