Robotics Studio Support?
yadranko
Posts: 11
What are the plans for supporting Microsoft Robotics Studio?· If not, what about any version of Basic language?· I think that whereas Assembler and Spin are cool, and·so is Linux, but it is just to-much to bear for some of us.· 
·· There should be·easier way of programmig the Propeller chip.· Any plans to adress this issue out on a horizon?
Thanks for any response!
·
·· There should be·easier way of programmig the Propeller chip.· Any plans to adress this issue out on a horizon?Thanks for any response!
·
Comments
With the Propeller, you have a lot more power than with a BASIC Stamp, and you can also do multitasking with the 8 cogs, so it wouldn't be very interesting to use it only to send and receive data from a computer. In this case you would use a less powerful chip.
But anyway, if you already had a project all set up with a propeller chip, then you could definitely write your own MSRS services to communicate with the PC, and that would also allow you to use more sophisticated programming languages, like C#.NET, VB.NET and all the other .NET languages, and also all the other libraries available on a computer (windows forms, vision, speech recognition, etc.). But again that could be done with any other MCU. (Although you would have to connect a camera or a microphone to the computer instead of the microcontroller, or it would have to send that data, therefore slowing down all the rest. For this purpose, there are many wireless cameras available)
If all you want is only a more standard language than Spin, you could wait for the C compliler that is being developed by ImageCraft (http://forums.parallax.com/showthread.php?p=646370)
Hope this helps,
Alberto
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My blog: http://alandtech.blogspot.com
Thanks for the response. I completely understand everything you've written and it makes sense. One of the reasons why I find Propeller attreactive (besides multitasking) is the fact that Propeller has many IO pins, great deal more than any other chip I am aware of. I need a controller that can power many motors and query many sensors at the same time, and still be able to do other things. Up until now I used microcontrollers with multiplexers to get all this accomplished, quite expensive and processing power intensive to do.
The way I would like to marry the Robotics Studio and Propeller is in this way:
1. Propeller handling low level task routines directly, such as basic leg positioning, and
2. Propeller passing on other more global data such as orientation and laser rangefinding data to the PC & the Robotics Studio for further calculation, instruction, and presentation.
3. Propeller receiving instructions from Robotics Studio which also interacted with other robots/sensory and processing hardware (collaboration)
Having studied Propeller for some time I am quite sure that it could handle all this alone, however the programming would be cumbersome due to the difficult programming languages. I wanted to avoid having to dedicate so much time on just learning how to use the tools, instead of just using them and focusing more of my energy elsewhere.
C language isn't too-much programmer friendly either; /*but might be worth a look. */
Thanks for all the info, I'll keep digging into Propeller's possibilities.
There are two ways to use Basic. Mike Green has contributed a really neat, very heuristic micro-Basic in at least two flavors. And a couple of guys have used VB to implement a terminal program, which would allow you to use pre-made Spin objects for your sensors and motors and use VB for handling higher level logic. I would guess that you could put a VB program in between MSRS and your Propeller based robot. Then you could use VB to implement your "glue" logic in between your Prop-based robot and MSRS.
The nice thing about the implementation of language services for the Prop is that you don't have to know very much Spin to get things working. Just the basic concepts and an appreciation of how to use objects will get you a prototype... maybe not exactly what you need but close enough so that you can know exactly where to concentrate your efforts. Much of what you might need has probably been done, and it is simply a matter of getting to the point of figuring out what you need and then asking where it is.
I've never worked with MSRS, so I don't have a clue as to its actual architecture (OR how poorly suited that architecture might be to optimizing machine performance around the Propeller). My guess is that the MSRS platform will turn out insufficiently deterministic to do cutting edge work with the Prop... regardless of implementation.
We have already seen basic physics objects, work on generating standard 3D formatted data, and imaging. When all of the developments converge, surprisingly advanced levels of machine control and simulation will be possible. In terms of image data, there has been recent attention given to memory architectures, which can remove some of the perceived bottlenecks. Most of the effort has concentrated on single processor models, but highly parallelized approaches could theoretically achieve almost any level of imaging performance (with a very reasonable price/performance ratio, which will only improve with the next generation of the Propeller.)
What is important to remember is that we are in just the second season of development. The real surprises are ahead of us. From a standing start a little more than two years ago... to where we are today... amazing, phenomenal, surreal. AND unlike almost every other option, nothing is hidden. All of the information you need is freely available. Finding it can be a challenge, but it is all there.
I also hate new languages... but Spin is different. Any effort you make will come back to you many times, anything that you learn will have persistent value.
While you didn't mention it, and this might not be an issue for you, there is also the issue of native languages.
If English is your second language, the available documentation might easily appear more complicated than the material really is. There is an active forum in German and a growing list of Spanish participants. If PropEnglish is a problem, you can always post your question in your native language.
Many of our contributors are multi-lingual. (And what comes out of my Google/Safari interpreter is always entertaining[noparse]:)[/noparse]
Regards,
Rich
ILMP
I would forget the MSRS for now only if I can get an interpreter that would translate Visual Basic or any sort of Basic into Propeller Assembler instructions and load them into the propeller chip. I am thinking that if such a thing is possible with the Propeller I should perhaps dedicate in creating such a compiler/loader. Or we could start a community project [noparse]:)[/noparse]
English is my second language but that isn't an issue for me.
I'll keep fiddling around and scour forums and contributions sections for clues on how to simplify programming. Maybe I'll even fall in love with SPIN while doing so [noparse]:)[/noparse]
Having a Basic compiler would not help you significantly with the need to learn new concepts in multiprocessing and multiprogramming using the Propeller. Most of the "advanced" hardware features would look no different in Basic than they do in Spin and making use of the highest speed and determinism require assembly language no matter what you use for the "glue" language.
A number of people have posted similar requests for Basic or C as a supported programming language for the Propeller and talk about Spin being hard to learn or imposing or otherwise too difficult or too onerous to tackle. Well, C will be available in the next few weeks, but it probably won't solve a lot of people's problems. Compiled programs will be larger (though much faster) than the Spin equivalents and some applications will need a different balance between speed and space ... more like what Spin provides. On the other hand, the C compiler will allow some programs that were too slow in Spin to be practical without resorting to assembly language (which the C compiler will also support).
Back to Basic ... Keep in mind that things like strings and floating point are very expensive to implement in a processor with limited (32K) of memory and only integer arithmetic. Keep in mind that the Propeller does not include standard I/O devices of any kind ... although there's support for a variety of displays and other I/O, none of it is "standard". There's no minimum set of I/O.
What features would you want? Would you be satisfied with an integer-only Basic? What kind of string handling would be acceptable at a minimum, if any? Having some features implemented optionally (like floating point and strings) doesn't always work the way you think. Sometimes using one feature brings in a whole lot of expensive (in memory requirement) support for other features that you don't realize you are requiring. How much would you pay for such a compiler? The C compiler will cost maybe $200 with a limited license and perhaps $500 with a full (commercial use) license. A full featured Basic compiler would be no cheaper. Remember that most of the unique Propeller features are not describable in Basic except as subroutine or function calls and some features would not be usable fully without some recourse to assembly language.
It's not very practical. A lot of the power of the processor is in very specialized instructions that combine several functions ... like having conditional execution flags in every instruction or a combined compare and subtract instruction for simplifying division routines or that most logic arithmetic instructions compute the parity of the result (for implementing linear feedback shift registers). It's very difficult to use this kind of functionality from anything other than assembly language and there's not a lot of functional density (what gets done per byte of generated code) in the native Propeller instruction set otherwise.
Probably the best thing would be to translate Basic into an interpretive code and provide a "tight" interpreter much like what Spin does. Again, there's the development expense. Parallax will not invest in that. Spin already exists, works fine thank you, and many people are just fine with learning it. There is simply not enough reason to devote the substantial resources necessary to implement a whole new system. ImageCraft is doing their C system because they already have it for other chips and can cheaply enough modify their existing system to generate Propeller "Large Memory Model" code.
32 I/O pins.
You can get that from a 40-pin PICmicro and others and you will also get multiple channel on-chip 10-bit ADC's. They aren't particularly hard to network ( serially or as I2C slaves ) and you can get a number of smaller chips for the price of a single Propeller. You won't need an external I2C Eeprom to boot from and it won't take a couple of seconds to boot. You won't need an external crystal and can have more accurate timing. Most will run on a voltage of anything between 2V an 6V.
There's nothing fundamentally wrong with the Propeller ( I do miss on-chip ADC's and not having an accurate internal oscillator ) but as a simple I/O controller it's not necessarily the best solution, and the I/O count isn't really a convincing argument in its favour in such a role.
For that matter, Parallax's SX chips have lots of I/O pins and there's a free Basic compiler you can download. There are several tutorials on the use of SX/Basic and Jon Williams wrote a couple of Nuts and Volts columns on its use ... also downloadable from Parallax.
The SX-48 Protoboard has 36 I/O pins and sells for $10. It doesn't have multiprocessing, but the interrupt mechanism provides for doing multiple virtual peripherals (like timers and UARTs).
What would I consider easy programming language? A language that most naturally comes close to English, that would be Basic, Visual Basic, etc. I am a programmer myself and have used Assembly, Java, C++, VB, C#, and VB.NET amongst few others. Also have programmed Basic Stamp I & II and object hardware OOPIC controllers.
On your second response on translating Basic into Assembly: I meant programming in Basic and using the compiler to translate the code into assembler or machine code while on the PC and which would then be uploaded to Propeller. Yes, your second part of the response confirms what I'm talking about, but as you said, Parallax might not want to commit to it. That's why I'm wondering whether to start a community project on this. Why not cater to audience that likes Basic type of language as well [noparse]:)[/noparse]
I meant that number of IOs was one of the reasons for me, not the reason [noparse]:)[/noparse] Going off-topic, but I thought most Basic stamps had 16+2 IOs, ah that 42 pin one. You intrigued me with this SX-48 proto board, somehow I never paid attention to it. [noparse]:([/noparse]
I thought a couple of tutorials said that Crystal isn't required for Propeller, except??. Stamps running on 2V, I'm puzzled, are you sure? I've got so much to learn -_-
Will check those sticky posts again too [noparse]:)[/noparse]
I mean, couldn't we make a compiler that does this:
Dim MotorNumber As Integer
Dim MotorDirection As String
MotorNumber = 2
MotorDirection = "CCW"
setmotor (MotorNumber, MotorDirection) 'function that turns specific motor in specific direction
understands the almost plain English code (understood by grandma) above and translates it into machine code (the code noone needs to care about how it looks like) to be uploaded to the propeller:
MOV addr, par
ADD addr, #6
etc...
OK, I went too-far this time [noparse]:)[/noparse]
The Propeller has an on-chip oscillator so no Crystal needed, but there's a wide range of speeds any particular chip runs at, 12Mhz nominally but anywhere between 8MHz to 20MHz.
Stamps and others I cannot comment on, but certainly some PICmicros can go down to near 2V.
For the MSRS thing, I think you shouldn't bother using it, since writing the core services (which can be done in any .NET language BTW, including VB.NET, although VB.NET isn't that similar to VB as you might know) can be a pain. I agree that when it comes to using those services, it is a great tool (I'm using it quite much now for my robotics stuff, especially with mindstorms stuff, and I'm trying to start writing the core services in order to use MSRS with my team's internet controlled robot, SYR), especially for robotics.
But another thing you could do, is write the base stuff on the propeller, as you said earlier, and send data to the computer via serial port connection (using bluetooth probably), and then just communicate with it in VB.NET, since you seem to like that language. You would only need to write the communication stuff, which is made pretty easy by the .NET library (just use the System.IO.Ports.SerialPort class (check it out on msdn)). Then you could do whatever you want, once you have written the appropriate setmotor() and other functions you need, that would send and receive the right serial data to the propeller chip.
If you need any help with that SerialPort stuff, I would be pleased to help you out [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My blog: http://alandtech.blogspot.com
Sure grandma can understand the code and that's a great example, but you are talking about two very very different conceptual levels. The Basic sort-of level you're describing is making a whole lot of assumptions that have large implications in terms of memory and computational resources. For example, what kind of motor is it? A servo motor, stepper motor, and DC brush motor all have different hardware and software needs. I can have two motors, one that moves clockwise and one that moves counterclockwise and, if they're different types, it might mean that the Propeller needs to use one cog for each one and two completely different sets of library routines that might (because of their generality) each require 1.5 to 2K bytes of memory. That might represent 10% of the available memory right there and 25% of the available cogs. Similarly, a single use of floating point in a program might require the use of 1 or 2 more cogs and another 4K of memory. A general purpose string package might need several K bytes of memory and just the one use you gave might be enough to require the whole package to be included.
On the other hand, there's not a lot of conceptual difference in:
OBJ servo : "Servo32" CON CW_Direction = 1000 ' Control pulse width for full CW rotation Stop_Motor = 1500 ' Control pulse width for nominal stop CCW_Direction = 2000 ' Control pulse width for full CCW rotation motor_1 = 10 ' I/O pin used to control motor # 1 motor_2 = 11 ' I/O pin used to control motor # 2 PUB mainProgram servo.set( motor_1, Stop_Motor) ' Initialize both servos servo.set( motor_2, Stop_Motor) ' to a stopped state servo.start repeat ' Now rotate each motor servo.set( motor_1, CW_Direction) pause(1000) ' with 1 second pauses servo.set( motor_1, Stop_Motor) pause(1000) servo.set( motor_2, CCW_Direction) pause(1000) servo.set( motor_2, Stop_Motor) pause(1000) PRI pause( milliseconds ) ' This would be a library routine waitcnt((clkfreq/1000)*milliseconds + cnt)There's some detail (like initialization) that your code fragment doesn't have,
but this is pretty clear once you happen to know that you have to define an
initial state for the motors you are controlling before you call the start routine.
There's no point in compiling this into the native instruction set because none
of this needs to be particularly fast and the Spin interpreter is already included
in ROM and the Servo32 library routine already does an appropriate mix of Spin
and assembly language to accomplish its functions.
As an aside, the above program can be written and run in BoeBotBasic which has
provisions for controlling two servos and the timing ... all of this on the Propeller
itself. The interpreter is slow, but adequate for a lot of control functions. There's
a simple navigation program written in it that uses the PING and IR distance
sensors for obstacle avoidance.
It is not the language, it is the concept of what *you* want to do and how good you understood to express your wish in that language. The mainstream of languages are quite easy (as soon as you know one), some are stupidly complex (C++; my most hated language), some are brilliantly simple and flexible (Objective-C).
Spin is a language that has its flaws and limitations, but it is neither complicated nor primitive. And what's the most, it perfectly fits the processor and doesn't hide its capabilities.
Think about Occam, a language that was designed for parallel processing. Any other off-the-shelf-language would have had its problems with an transputer.
Design your task (flowcharts or whatever) and cast it in the language available. Spin won't stop you from doing that, it will support you.
Nick (counting well above 15 programming-languages, most of them forgotten)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Folks, I am not really arguing here for myself but for the so many folks that turn down robotics due to rocket science involved in programming. I led a special interest group Robotics at my university for 6 years and have seen so many guys and girls losing interest in a very short time, mostly due to tendency to fall asleep when it comes to explaining or teaching programming part. I want to capture the would be casual (non-hard core) robotics junkies and for that to happen things need to be simplified further. No, don't send me over to Lego. I am looking for tool which I will learn completely just as most of you have, but then use my programming skills to simplify it through use of compiler interpreter so that beginners will want to play with it for more than just 15 seconds. You and I are more of a hardcore, much more you than me, and doing cool things with memory and registers is indeed cool, but the would be casual robotics junkie will get scared by that. Arguing performance and drawbacks while just trying to make tools that are easy to pick up for a beginner in my mind isn't the right approach. Get out of the box and tell me a simpler way, I don't care about all the mind boggling coolness of pointers, give me the functions that accomplish it, I don't care about the details of how an engine works, show me how to drive the car, I might get to the engine part later on when I'm hooked!
OK, the more we go on about this the more I believe I might be able to do what I kinda intend to do [noparse]:)[/noparse] and that is make a English to Spin-Assembler (speech to spin/assembler code or text to spin/assembler code) interpreter. Just as Mike said, we are talking about a different conceptual level, a higher level abstraction: machine code<-Assembler&Spin<-Basic<-English. I like his code example but would want the initializations to come free of charge by the compiler. I'll give it some more thought.
My question now is: is there a freely available documentation around that would tell me how to program the connection and code upload part between my homebrew [noparse][[/noparse]EnglishPropeller v1.0 compiler] and [noparse][[/noparse]Propeller chip]? Or would my only way of uploading be by just copying and pasting SPIN &/or Assembler code from my compiler into the Propeller Tool and then upload from there?
Language:
If you want to design your own, go on. If that is the frist time for you, you'll find out that it is a long road. I would suggest something that works like the UCSD-p machine. Produce p-code for a virtual processor and the op-codes interpreted on the Propeller. Very compact code and not as slow as fully interpreted. A p-code interpreter certainly fits into a cog.
If you -by chance- do speek German, try to get the book "Compilerbau" by Niklaus With. Incredibly compact book, well describing what you need with a small compiler for a PL/I-ish language and an p-code interpreter.
Processor:
The Propeller is a micro-controller, not a CPU! It doesn't have much RAM and thus you'll soon end with an "out of memory" if you try to make a task too complex.
If you are dedicated enough, you could write a p-machine on the Propeller that fetches the instructions from a big EEPROM and interprets it, leaving you more RAM for variables. I thought about that some days ago and think it can be done (but I won't do it).
And yes, it is described how to download code to the Propeller. You don't need the Propeller tool for that. But I don't have the link at hand, others will jump in.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
It was written to illustrate the download protocol.
http://forums.parallax.com/showthread.php?p=591445
Here's a link for a downloader written in Python
http://forums.parallax.com/showthread.php?p=622354
All of these and more are kept in the "sticky" threads at the top of the Propeller forum thread list.
There's a lot to explore there, but worthwhile to at least glance through the lists.
here's the link to the post on the MSRS forum:
forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2421047&SiteID=1&mode=1
Edit: Actually this guy says that it's going to be the same BS2 MSRS services, but the code on the Propeller will be posted, which means the communication protocol and the data sent would be the same...
I was hoping there could be more precision with the IR stuff (it's just boolean data for now), and maybe a PING turret alternative... perhaps it will come one day...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://alandtech.blogspot.com
Post Edited (bietz) : 11/16/2007 9:43:28 PM GMT
I hope that what they post about this doesn't get burried someplace so that we can't find it.
Post Edited (yadranko) : 11/17/2007 6:34:18 AM GMT