Great!!!! I got my New Propeller BOE :-( now I really am lost

smithdavidp

I have about 10 hours into figuring this thing out. I have had some progress but I am totally lost as far as how it handles the pin designations. With my BS2, BOE, I understood what, and how, pins are designated. If I want my left servo to work I pluged it into the number 12 header and the name of that servo became P12. All of the examples I am reading like:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
PING_Pin = 0 ' I/O Pin For PING)))
LCD_Pin = 1 ' I/O Pin For LCD
LCD_Baud = 19_200 ' LCD Baud Rate
LCD_Lines = 4 ' Parallax 4X20 Serial LCD (#27979)

leave me confused. My Ping sensor is pluged into the P17 header, the servo to turn the sensor in pluged into P16, the right continous servo is plugged into P15 and the left continouns servo is pluged into P14. Am I to assume that the number that goes after PING_PIN=0 should be changed to PING_PIN=P17? The same with the servo examples SERVO,0 SERVO,1 should be replaced with, in my case, SERVO,P14 SERVO,P15? I don't want to burn somthing up, or out for that matter, due to my lack of knowledge.

I was new to this with the Basic Stamp but the instructions made it easy to follow. There are a great number of examples to follow but few "nuts and bolts" type of pictures. For example "If you plug in your right servo to the Header marked P17 be sure to remember that the BS2 program will use P17 when it activates the Right hand servo. Lets test that now". A picture showing the connector on the P17 header would be shown and then a short routine to test the operation of the servo would be given. I understood that. But saying that Spin is simple to learn or it's easy as cut and paste is beyond me. I'm not following the materials that I downloaded and most of the other materials refer to different animals then the one that I have. The section about controlling multiple lights was great.....but past that there is only examples of code with no schmetics to know where I am going or what I am doing. I saw there is a section comming about using the Propeller BOE on the BOE- BOT chassis. I hope it is as good as the "Robotics with the Boe-Bot" manual that arrived with my Boe-Bot kit.

Ttailspin

Am I to assume that the number that goes after PING_PIN=0 should be changed to PING_PIN=P17?

No, just PING_PIN = 17. drop the P...

This is slightly advanced, and I think I have this right, You can also do this..
PING_PIN := P17 := Purple17 := jello9 := 17
But why you would want to name your Ping sensor Pin "jello9" or "Purple17" is beyond me, and is only an example.


-Tommy

Mike Green

The pin stuff is actually pretty much the same as with the Stamps. With the Stamps, you have 16 essentially identical I/O pins, numbers 0 through 15. Because of the way the Stamp Board of Education is set up, there are a couple of sockets intended specifically for things like servos and PINGs that need power and those sockets are hooked up to specific Stamp I/O pins. Similarly, the Propeller BOE has 32 essentially identical I/O pins, but some of them (20 - 31) are used for some of the built-in features like the ADC and for programming. I/O pins 0 - 13 are brought out to breadboard sockets and 14 - 19 are brought out to the powered sockets for servos and PINGs (and other similar stuff), but they're all just I/O pins ... pretty much all identical.

The names are for convenience and for documentation. You don't need to use the names, just the numbers, but they sure make things easier to understand. As you said, if your PING sensor is plugged into the socket for I/O pin 17, you'd define a name PING_PIN like:

CON PING_PIN = 17

This assumes that the rest of the example uses the name PING_PIN.

GordonMcComb

There are some existing docs that can help you. In case you haven't seen it yet, theck out the entry-level info here:

http://learn.parallax.com/PropellerBOE

which gives Spin programming examples and hookups specific to the PropBOE.

You can also use the KickStart guides here:

https://sites.google.com/site/parallaxinretailstores/

The diagrams are for the Propeller QuickStart board, and new pictures showing the PropBOE are coming later this next week. But in the mean time, just ignore the "P" in the labels on the PropBOE. Other slight changes are:

* Anytime it says to connect to Vss plug into a PropBOE Gnd pin
* Anytime it says to connect to Vdd plug into a PropBOE 3.3V pin
* Anytime it says to connect to Vin plug into a PropBOE 5V pin

Bookmark the KickStart page for the updates coming this next week.

-- Gordon

Duane Degn

smithdavidp wrote: »

I saw there is a section comming about using the Propeller BOE on the BOE- BOT chassis. I hope it is as good as the "Robotics with the Boe-Bot" manual that arrived with my Boe-Bot kit.

I also really liked "Robotics with the BOE-Bot". I agree, it would be great to see such a book written for the PropBOE.

I posted a couple of programs in the Robot Forum. One program just holds the wheels still to make it easier to calibrate the servos. The other program makes the robot drive forward and then drive backward.

smithdavidp

Okay. So all the Prop is looking for is the input, or output, pin. Since I have the Ping connected to the P17 connector all I have to tell it is that, in this case, the input will come from pin 17. If it were a servo then all I have to tell it is that the output will go to pin 16. The name doesn't matter but is useful to backtrack when I have problems. Is this correct? If my servos were connected to the P 14 and 15 headers then I should also be able to jumper P14 and P15 from the header, near the breadboard, to one of the LEDS to confirm proper engagement of header pins P14 and P15 without actually having the servos pluged in?

Mike Green

Yes

The names aren't so much used for "backtracking" as they're used instead of the numbers in the rest of the program wherever the number would be used.

smithdavidp

Thank you. I must say I should have posted this 14 hours ago. Can't say it gave me grey hair cause my hair is already grey but your help surely releaved a lot of my heart and head aches. Once again Thank You!

smithdavidp

One last thing and then I should be set. I am an old mechanic so I will put this in terms that I understand. Lets say I want to rebuild an engine. The parts kits I need to do this are at the parts counter (Library). I need a Gasket kit, camshaft, piston rings etc. These are the [OBJ]. Rather I need everything from each kit (OBJ) or just a few items I still must have the entire kit (OBJ) because that is the way it is packaged. Some of the kits (OBJ) may require other kits (OBJ) to complete all the parts I need to build the engine. Besides parts people love to make money. Now I start to build the engine (PUB) and write down the order in which each part (OBJ) is to be used or installed. During the build there needs a decision to be made rather a part will, or will not be needed (PRI). The engine is completed, started up and runs. Now a list needs to be made of what, and where, each item came from (DAT). Once completed then the rebuilt engine can then be seen as another part (OBJ) but it must contain all of the parts used (OBJ) before the engine is installed in a vehicle (New Spin Object) Engine.spin.

If this is, indeed, how Spin works then I think I understand what is going on. It seems to me that putting all of the objects in the library directory would be the thing to do. Searching for what you need to complete a project is narrowed down to a single directory. Then copying the objects to a specific directory, that contains your project, is just a simple matter of copy and paste to the new directory.

Thanks for your time.

Mike Green

Your way of thinking about objects is pretty good. The PUB vs. PRI analogy falls down a bit and the DAT analogy doesn't make sense, maybe because it's too limited.

PUB methods and PRI methods are the same except that the PUB names are available outside the OBJ while the PRI names are PRIvate to the OBJect. A better analogy would be that a PRI tool might be like an adjustment tool needed to install a kit, used nowhere else in the engine.

DAT is used for several things. I don't know what the assembly language analog would be and it's use to hold variables common to several instances of an object might not fit your rebuild analog.

Objects can be kept in the same directory as your main program file and they can be kept in the library directory. Some objects are indeed "library" objects and might / can be used in lots of different programs. Those go in the library directory. Other objects are just used for your program. They are not designed nor intended for use by other programs. Those go in your program's directory. Sometimes these unique objects become more useful generally over time and might, after cleaning up, be suitable to move to the library directory for more widespread use. Sometimes they might be so useful that it might be good to package them up with some documentation and examples of their use and submit them to the Object Exchange for others to use.

smithdavidp

I thought I had it. If I were in better health I'd fly out to California and take that class in April. The only programming I have had was basic in the late 80's and Pascal (5.5) in the early 90's. C and C++ were starting to come into their own about that same time. Top down object oriented anything is as foreign to me as speaking Japanese or German (which I can speak a little of both). I will be vigilant and watch for anything that comes up but I may be a pain in the mean time. I am learning by reading the documentation that I have downloaded and looking at spin code which has also been downloaded. A final, parting question. The Ping sensor shows a 1k or 100k resister on the data line when it is plugged into the Prop demo board. Is this also necessary with the Prop BOE or will it work in the same manor that was used with the BS2 board? Thanks for your time.

Mike Green

The most recent recommendation for a resistor value is 3.3K and, yes, you need it with the Prop BOE. The reason is that the PING operates with a 5V power supply, so the output pulse from the PING goes from a little above 0V to a little below 5V. The Propeller, no matter which board, is a 3.3V device. It's input pins are not designed to handle voltages above about 3.9V. There's a diode built into the I/O pins that's connected between the I/O pin and the 3.3V supply on the chip. Any voltage above 3.3V + 0.6V (the forward voltage of the diode) = 3.9V is shunted to the power supply. The problem is that the diode is intended to help absorb static zaps, not connections to 5V pulses, and the diode can only sustain currents of about 1/2 mA without damage. The series resistor keeps this fault current below where it would cause damage from the PING's 5V pulses.

I have one of Parallax's nice 3 wire cables with the 3-pin sockets on each end to use to connect the PING to my Prop BOE. I snipped the white lead about an inch from one socket and soldered a 3.3K resistor between the stripped wire ends, then insulated the area with stretchy vinyl electrical tape. Works fine.

smithdavidp

The haze is lifting and I can see the runway. I have a Ping sensor that works, 3 servos that behave as they should, and XBees that talk to each other. Next is the GPS, temp/hunid sensors, and compass. Do you think it is time for me to move up to a little larger chassis? Should I split up some of the functions between two boards instead of pyling it all on one board and a Boe Bot chassis? I think I am starting to get a little out of controll. Remember....my project is to build a sentry bot that can respond to someone in need of help. Then it can dial 911 with an automated voice. And it can carry on a limited conversation and responde to limited basic commands. But I am concerned about the amount of power it will draw down and the amount of information it will need to process. I still have my BOE BS2 board collecting dust. A little direction would be nice. And a recommendation of sensors needed would be awesome.

Duane Degn

smithdavidp wrote: »

The haze is lifting and I can see the runway. I have a Ping sensor that works, 3 servos that behave as they should, and XBees that talk to each other. Next is the GPS, temp/hunid sensors, and compass. Do you think it is time for me to move up to a little larger chassis? Should I split up some of the functions between two boards instead of pyling it all on one board and a Boe Bot chassis? I think I am starting to get a little out of controll. Remember....my project is to build a sentry bot that can respond to someone in need of help. Then it can dial 911 with an automated voice. And it can carry on a limited conversation and responde to limited basic commands. But I am concerned about the amount of power it will draw down and the amount of information it will need to process. I still have my BOE BS2 board collecting dust. A little direction would be nice. And a recommendation of sensors needed would be awesome.

I don't think anything you listed yet would require a second Prop. I think the BS2 would be more bother than it's worth.

There are a lot more choices of sensors now than just a few years ago. Any sensor I recommend would likely be out of date.

I have looked a humidity sensors lately. The SHT11 (IIRC) works pretty well for measuring humidity and temperature.

GPS is kind of tough. I made a GPS logger a while back and all the full featured GPS objects used several more cogs than they needed. In order to save a few cogs, I had to move many of the child objects into the parent object. Hopefully I missed something, but I was disappointed in the GPS choices I had to choose from last summer.

I imagine you've noticed the BOE-Bot has a hard time moving around on anything but a smooth floor. I don't think you need a larger chassis because of the added sensors, but you might what to use a robot with larger wheels and more powerful motors so you can move on carpet and over small obstacles.