View Full Version : BS2 Communication with Matlab

01-27-2006, 08:11 PM
Hello. Does anyone know if i can communicate the BS/2 with matlab;; can i load files with code from matlab to BS/2. More specifically i am interested in the robotic arm toolbox of matlab. thanks.

Post Edited By Moderator (Chris Savage (Parallax)) : 1/27/2006 3:01:33 PM GMT

Paul Baker
01-27-2006, 08:16 PM
Its been many years since I played with Matlab (grad school), but the libraries were quite versatile. You need to find a library to do RS232 communications, that would be the easiest means for communication between BS2 and Matlab.


01-27-2006, 08:46 PM
hello paul thanks for your reply. do you know if the code of matlab would be acceptable by BS/2.

Paul Baker
01-27-2006, 09:19 PM
You would have to come up with your own communication commands, This could be anything you want as long as it conveys the information. Say you have a real world 3DOF + gripper robotic arm controlled by the stamp which in turn gets its commands from Matlab. You could label the three servos A-C with a range of motion defined as 00 through 99, so to move the second servo to 75% Matlab would send B75 across the RS232 connection. For easy of programability youd probably want all the commands to be the same length, so you could define gripper open and gripper closed as GRO and GRC. But what you actually use is really arbitrary and up to you, as long as you have Matlab and the Stamp in agreement of what the commands mean.

<edit> since the stamp has an easier time dealing with numbers in thier binary format, you proably want the command structure to be a single ASCII character followed by a binary number so something like 'B'<75> where 'Letter' is ascii and <number> is binary, and 'G'<00> etc. </edit>


Post Edited (Paul Baker) : 1/27/2006 2:25:00 PM GMT

Bruce Bates
01-27-2006, 09:46 PM
Gents -

So long as the number formats are consistant, and NON-decimal, the Stamp should have no problem processing them. I would run at the lowest baud rate that MatLab will support, at least at the beginning, you can always boost it up later if necessary, or desired.

Since you are defining your own "command language" here, I would also consider the rather heavy use of delimiters (commas, parenthesis, brackets, etc) which will permit you to use the (limited) string handling facilities in the SERIN formatting sub-commands. You can also use the SKIP sub-parameter to skim over the trailing delimiter if desired.

LONG before I ever put my hands to a keyboard to write the MatLab or Stamp programs, I would spend a GOOD DEAL of time with a pencil and paper developing this language, and design it as logically and in as straight forward a manner (as Paul has done in his examples). In the end you will find this is time VERY well spent, particularly since it may well be adopted for use by others wishing to do the same or similar things.

Although I know nothing about MatLab, I do have some experience in developing command languages, and to the extent that you can provide appropriate MatLab documentation, I would be happy to lend a hand. Contact me off list if you wish (see below).

Lastly, due to the availabilty of the SPSTR area (64 bytes of scratchpad RAM), I wouldn't use anything less than a BS-2SX for this project. It will also provide more "horsepower" to do the necessary string processing.


Bruce Bates
bvbates at comcast dot net
(reassemble before use)

Kevin Wood
01-27-2006, 10:11 PM
The Basic Stamps are programmed using PBasic only. You can't load non-PBasic code into a BS2 and run it.

If you want a BS2 to communicate with Matlab, you will have to program the BS2 in PBasic to communicate with Matlab, and program Matlab in the Matlab language to communicate with the BS2.

Your mission, should you choose to accept it, is to determine the best algorithm to control your robotic arm, and implement it within the capabilities of your chosen platform.

Paul Baker
01-27-2006, 10:54 PM
Ok after thinking a little more on the subject (nothing better to do while waiting 20+ light changes at an intersection because of an overturned vehicle in the middle of the road), I think it isnt completely nessesary to use delimiters, if your binary value transmitted is restricted to values 0 through 99, that leaves the values 100 through 255 "unclaimed", if you choose ascii characters whose equivalent binary values are in this range, the stamp will know irregardless of the use of delimiters whether the byte recieved is the prefix or suffix to the command.

Convieniently the lower case letters d-z satisfy this criteria, so you could use x,y and z for your servos and g for your gripper. The reason delimiters are used are for frame synchronization (so you know what is the first byte in a sequence of bytes), but by using the above scheme you know on a byte by byte level if it is the first or second byte.

Also you may want to include hand-shaking in the RS232, this is because the stamp can only do one thing at a time, so the stamp may not be listening to the connection when Matlab sends a command, if the stamp starts listening and instead of receiving the first byte ('x','y','z', ot 'g'), it receives a number it knows it missed the first byte and does not acknowledge successful receipt of the command sequence, Matlab noticing an acknowledge wasn't given sends the same command again, and will continue to do so until the stamp finally acknowledges it recieved the full command sequence. This way even if the stamp misses all or part of the command sequence because it was busy doing other stuff, you can guarantee that eventually it will receive the command when it finally starts listening to the connection again.


Post Edited (Paul Baker) : 1/27/2006 4:07:28 PM GMT