Mailman 3 March 2001 - Edu-sig

Re: [Edu-sig] The Educational Robotics Platform
by Stephen R. Figgins 20 Mar '01

20 Mar '01

Thanks for the reply, Steve. I wondered about Jython on leJos as well. Think I will ask about it on the Jython list. Let me see if I understand you correctly. JavaVM fits in smaller places than Python because it was written tight from the start. uController's are often very small memory systems, 64k maybe. So you're VM (and with Python we use this term very loosely) has to fit in about 32k or less. Getting down that small is essential if you want to have a robot price-tag of $100 or under - which would be, in your opinion, the threshold to broadly introducing robots in the classroom. Because Python was not written with such small memory environments in mind, it is hard to retrofit it. You end up trying to rewrite the core so you can leave out things. (Pippy for example can get down to about 70k, if you chuck the parser/compiler, floating point, and some other stuff.) You doubt that Python can get down to the 32k requirements to fit it on the cheap uProcessors. Stephen

1 0

The Educational Robotics Platform
by Arthinator＠aol.com 19 Mar '01

19 Mar '01

Python-centric educational robotics, in process http://eggo.sourceforge.net/ Aimed at middle school. Site has a lot of documentation on the project's intentions. Quite interesting. ART

4 4

The Educational Robotics Platform
by Arthinator＠aol.com 19 Mar '01

19 Mar '01

>At the high end, use the complete platform and software suite (maybe the >graphical Control Station) to allow non-programmers to control an industrial >robot. >Always with an emphasis on the educatioal aspects. Wish me luck. You have a market anxiously waiting. From a survey of one - my son - the BattleBots show - Comedy Central cable network of all things - has piqued kids interest in robotics. But let the non-programmers wait - assuming by non-programmers you mean those who aren't willing to take on Python. Damn the GUIissies. Get around to them when you can. ART

2 1

RE: [Edu-sig] The Educational Robotics Platform
by Morris, Steve 19 Mar '01

19 Mar '01

Is a PC/104 based solution really any cheaper than the handy board and similar platforms? It isn't intuitive to me that there should be a cost benefit. The 68hc11 is a much more integrated solution (lots of I/O on the micro) than the x86 family (used by PC/104) which is really aimed at workstations. It seems to me that the strength of PC/104 is availability of software (for example Python) because it is xx86 based. It is not clear to me that it would end up cheaper, in fact the opposite seems more likely. Personally I would love to see a Python based robotics platform but I can afford a more expensive platform. Are you considering embedded Linux? Seems like an obvious strategy. > -----Original Message----- > From: Jonathan Pennington [mailto:john@coastalgeology.org] > Sent: Sunday, March 18, 2001 5:10 PM > To: edu-sig(a)python.org > Subject: Re: [Edu-sig] The Educational Robotics Platform > > > > * Arthinator(a)aol.com <Arthinator(a)aol.com> [010318 10:16]: > > Python-centric educational robotics, in process > > http://eggo.sourceforge.net/ > > Aimed at middle school. Site has a lot > > of documentation on the project's intentions. > > Quite interesting. > > Thank you! That's quite a complement coming from this list! > > And, of course, questions (and more importantly: suggestions) can be > made to me directly. I'm hoping to get a beta version by summer's > end. Including the code and documentation on controlling a number of > servo & motor controllers, sensors and other outputs. After the beta > and standard docs will be a lab-based manual. > > The EGg0 (that's a zero) system as a whole is currently being > developed around a PC/104 board, but all software > development is on my > Linux system with communication through a serial port and is being > "ported" to the embedded platform. Primary consideration is the use > of the software for all on desktop systems. I am developing an > entire platform with computer and controllers, however, so > that it can > be used at all levels of education from K-12 (with the software and > maybe Lego sets) through college and into industry (with the full > PC/104 board, GPL'd Real Time OS, and system software). > > The hard part is developing it so that the good people on this list > and beyond will still find the software useful, even if they > can't/don't get all of the hardware. GPL'd source is no good > if I only > program it for certain hardware. I'm trying to hit every major servo > controller and DC motor controller used in hobby robotics (Honestly, > not as hard as I'd thought, since similarities abound). The software > is a package of modules, with a seperate module for each discrete > controller, and a (hard|medium|easy) way to use them, so that all > levels of programming can be taught. > > I'll also be working up (relatively) inexpensive circuits and selling > kits (near cost) as well as posting the full parts lists and > schematics/diagrams. Hopefully, I can get cost down so that it's > available to all. Goal is that at the low end someone can > spend $20 or > less on supplies from Rat Shack, stick them all into a bread board, > connect them to a serial port, and control a couple servos while > learning to program with the software. At the high end, use the > complete platform and software suite (maybe the graphical Control > Station) to allow non-programmers to control an industrial robot. > > Always with an emphasis on the educatioal aspects. Wish me luck. > > -J > > -- > Jonathan Pennington | john(a)coastalgeology.org > > "A computer without windows is like a dog > without bricks tied to its head." > > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig >

1 0

RE: [Edu-sig] Teaching Python instead of Java?
by Alan Gauld 15 Mar '01

15 Mar '01

>Ah yes Symbolics... It is best to speak politely of the dead :-) There are still afew around! > say: both of these machines implemented a complex > abstraction in microcode. True but the microcode is part of the CPU hardware, you can't change it in any way.(OK pedantically a few experimental chips allow changes to microcode) > The underlying machines that interpreted the microcode > were procedural I disagree. Microcode operates at a level below procedures, it literally just moves data from A to B. The hardware synchronised by the clock operates on one set of bytes at a time, it has no concept of a procedure. If you ignore the microcode then the hardware is purely a bit twiddling function. > Microcode is more correctly called firmware > but so is PCs BIOS. No, there is a huge difference in the nature of microcode and BIOS code. As big a difference as between assembler and Python! Firmware is by definition replaceable, microcode, in general, is not. > There are/were non procedural computers but these > two computers are not in that list. I'll beg to differ, but I doubt the difference if strictly pertinent to this list so I won't argue either :-) Alan G

2 1

Raytressi - another few words
by Arthinator＠aol.com 15 Mar '01

15 Mar '01

Raytressi - the open source Python scripted raytracer I had posted up about: The distribution includes Python 1.5.2/Tk8.0, with, of couse, the Raytressi C++ compiled against it. Took Guido's advice re: the Lightflow thread - compiled the C++ under Windows against Python2.0. All is well, so that I now have a Python2.0 scriptable raytracer in a single .dll. Pleasing. Agree with Mark that the Pov-ray export utility for VPython works great, but since the raytracing I would be doing is fairly basic, and Raytressi looks quite competent - and can be part of a compact , self-contained Python-centric graphics exploration environment with VPython or PyOpenGL the dynamic/real-time piece... Have not yet responded to Guido's request for a edu-sig blurb on Raytressi - assume no one else has. Confronting French language and French educational system ignorance. But will follow-up once I get a little more familiar with Raytressi functionality, with something general enough to avoid the possiblitiy of having edu-sig page stating something inaccurately. ART

1 0

Re: Python for fun and OBP
by Jeffrey Elkner 15 Mar '01

15 Mar '01

Hi Chris! Let me introduce you to two of my students, Anoush Garakani and Scott Newman. They are both students in my CSC I and II class who have signed up for AP CSC next year. I've asked them to look at the Towers of Hanoi lesson and give us feed back. These kinds of lessons will be very useful to our CS program. I have been grappling for a long time on how to leverage Python to improve understanding in our AP course. I have not yet effectively done that. Next year I plan on using both languages in the course. Concepts will be introduced first using Python and then we will focus on the question, now how do you do this in C++? C++ syntax is so ill-suited to the task of teaching programming and slows down the pace of the course to such a degree that we always end up rushing at the end of the year to get to the topics that are really supposed to be the core of the course: data structures (lists, stacks, queues, trees, heaps), and algorithms (searching and sorting). These topics are well covered in the Java version of "How to think like a computer scientist", so I plan on translating the rest of that book into Python as soon as I can. If we can create a web site with both a text book and collection of activities and case studies, we will have a real resource for anyone interested in using Python to teach programming. Thanks for the lesson! jeff On 12 Mar 2001 12:58:08 -0800, Chris Meyers wrote: > Hi Jeff, > > Did the tower.py and tower.doc attachments come through? I'm > anxious to hear your impressions. > > Thanks, Chris

1 0

Cards n stuff...
by Jeffrey Elkner 14 Mar '01

14 Mar '01

Hi All! Could anyone point me to some good examples of classes for cards and decks, with shuffle methods, etc. I have a student writing a blackjack program, so the info would be a big help. Thanks. jeff

4 9

RE: [Edu-sig] Teaching Python instead of Java?
by Morris, Steve 13 Mar '01

13 Mar '01

> >'built on top of' procedural features (which are closer > > to how the computer really works). > > Closer to most computers but not all. Symbolics > workstations are optimised to work with Lisp and > Dr David H???? built an OO based machine some time > back for Linn Products which was all based on > message passing at the hardware level. But I > agree that most computers are stack based. Ah yes Symbolics... It is best to speak politely of the dead but this we can say: both of these machines implemented a complex abstraction in microcode. The underlying machines that interpreted the microcode were procedural, i.e. "how computers really work." Microcode is software and hides the underlying architecture but it is still there. There is little conceptual difference between a microcode interpreter and a Python interpreter. Neithor represent the actual hardware layer, i.e. "how a computer really works." Microcode is more correctly called firmware but so is PCs BIOS. There are/were non procedural computers but these two computers are not in that list.

1 0

Teaching Python instead of Java?
by David Pettersson 13 Mar '01

13 Mar '01

Hi, I work as a teaching assistant at my local university, and we currently teach Java only to our new students (Pascal was left a couple of years ago). Although Java is a nice language, I still feel that it is inappropriate to teach new students (some of which have had no prior computer experience!). I have been using Python for a couple of years now, but it was far from my first language (although one could say it is my primary language now :). What I am wondering is if Python is a better alternative, and why if is so. Sincerely, -- David Pettersson Stardate [-30]6312.44 dave(a)se.linux.org Public key available on request

3 3