LISP and Propeller

AIman

Hey guys and gals,

I needs some help here, its my first prop chip so these questions are going to be fairly basic.

First I looked at the Parallax website and saw that the starter kit came with a soderless bread board. Is that the generic one Parallax sells?

Second, I have a list of things I want to run with a propeller and wanted to know the best opinions on how to do these items, meaning who many cogs should be dedicated to what and how fast will the data cycle through the prop.

I want to use 2 solenoids, 1 servo/stepper motor, 10 PING))) and a camera.

The solenoid data is:
[*]Nominal voltage & current: 24VDC @ 333mA [*]Coil resistance: 44Ω (+10%) [*]Power consumption: 13.0W
From Jameco
http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=262191&searchValue=solenoid%20holding%20force%206.8

Stepper motor Data (from Jameco):
[*]4 phases [*]12 VDC [*]7.5° step angle [*]Phase resistance: 57Ω [*]Current: 210 mA [*]Phase inductance: 18 mH [*]Detent torque: 105 g-cm [*]Holding torque: 300 g-cm

http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=237892

The servo is from Mouser but I can't find the specs at the moment.

So given this how fast will the prop cycle through everything?

·I almost forgot to add the LISP part.

Lisp is the main program the prop communicates with in the host. There are a handfull of other sensors used, however LISP is the decision maker which means there needs to be an ability to exchange info between the two.

For this portion, how does the prop communicate? Also will the prop accept dropping information into LISP? Perhaps a better way to ask this question is how will the prop communicate with something else?
Are there specific datum to enter so that the prop data gets transfered over or does the prop need· translater of some form?

Post Edited (AIman) : 10/24/2006 7:27:41 PM GMT

Mike Green

There are many more questions to be answered before yours can be answered.

For example, how are you going to activate the stepper motors? What kind of stepper driver hardware are you going to use? Some people have done stepper driving directly from the Propeller. Figure one each cogs for the steppers.

Servos require a variable width pulse (0.5-2.5ms at the outside) every 20ms or so. There are existing routines in the Propeller Object Exchange for driving servos and figure one cog for anywhere from 1 to 32 servos.

The PING sensors don't do well if driven simultaneously since their transmitted ultrasound pulse can bounce around and be picked up by more than one sensor. If you're going to trigger them sequentially, figure one cog for that function.

I don't know what you'll need for the camera since you haven't given any information on that, but you'll need at least one cog for that.

For communication with a host computer, you'll probably just use a bidirectional asynchronous serial channel. There is a full-duplex serial I/O driver in the Exchange that uses one cog. You'll have to figure out what to communicate and how to do it in LISP on the host. Look at some of the I/O devices that Parallax uses with the Stamp. Many of them have a simple serial protocol for communicating. In particular, look at the AppMod devices on the Parallax website.

There'll be at least one cog for your main program. That's seven total. You could combine the two stepper drivers, but that makes the programming more complicated.

AIman

Thanks.

I have been contemplating driving everything straight from the host via LISP and as such am kind of torn between using the Propeller-LISP combo vs·straight common LISP.

The code is simply to much to post, so your assistance is greatly appreciated, however being new to Props makes things even more interesting.

AIman

One more thing, Jameco has the stepper drivers and the solenoid drivers. Mouser has the servo drives so those are easy to come by and fairly cheap.

One more question - for the hook up to the host - how fast and how much can I send both ways?

For example, can the Prop send all the sensor data continously? With the BS2 running 10 PING sonar it would take about a second to send and receive data. I need a turn time of 1/10th a second or less.

The camera is a simply JVC camcorder with an RCA jack.

The sonar are laid out in a pattern similar to a stop sign with all facing out.

The Prop is not capable of storing all the code so I pretty much have to use a host and even with a host it will be touchy. General Nano Systems based out of Minneapolis gave me a quote on a custom built computer that will hold 26 USB ports·because I will need 25 usb ports to run everything straight off the host. Otherwise I will need two Props and filter the data through LISP or else use 6 Props dedicating one Cog to each sensor/motor and leaving the rest open for talking to each other and/or the host.

·

Mike Green

The Propeller end can handle over 1MBps raw speed, but I don't think this is practical with most PCs without special programming. Figure using 115200 Baud or less, use checksums and acknowledgements, and keep the messages relatively short (100-250 characters). Remember that the steppers, servos, serial I/O, and PING processing is all going on in parallel. It's like you had 8 separate Stamps, but much much faster and more powerful.

Why do you need all those USB connections? The only thing that has a high enough data rate to justify more than one USB connection total is the video and I don't recommend trying to do video that way.

It sounds like you need to step back for a few minutes and figure out what you're trying to do before deciding how you're going to do it. The Propeller is a pretty powerful processor and can do a lot of stuff all at the same time. If you're planning on a master/slave type system, the communication between them should be at a pretty high level. Steppers and servos are really simple to do and don't require much communication. Look at the PSC (Parallax Servo Controller) documentation for one idea on how to do the communication. Steppers are not much different. There are several stepper controllers in Parallax's on-line catalog. Have a look at their documentation as well. The PING sensors really don't put out much information, just a time to echo reception and you really can't run several simultaneously without taking a chance on false echo reception from one of the others. Figure one PING every 20ms. That's a set of 10 in only 200ms. If you send the raw data, that's only 100 bytes per second or less than 1200 Baud. That could easily be done over a 2400 Baud radio link. Similarly, commanding the servos and steppers requires only an angular position and maybe ramping information and only when these change, not much information really, again really easy to do over a 2400 Baud reverse link (two links, one in each direction ... on different frequencies).

AIman

The drivers might be useable, however the Parallx motors and servos are far from the strength I need. Steppers for this project are rated at 5 1/2 lbs + of strength, the servo at 6.8 + and the solenoids at 7.8 +.

The USB ports are·1 for each·sensor.

PING is being used 6 at a time - but not in the same direction.

The video camera is for an object recognition·program I am writing. For the time being it will connect via rca but that is risky because of vibration factors.

All I really need to do is get readings back from sensors and make changes to the steepers, solenoids and servo based on the data from the sensors and camera.

Post Edited (AIman) : 10/26/2006 4:13:07 AM GMT

Mike Green

My reason to refer you to the Parallax servo controller and the stepper controller is not that you would use them, but that the kind of information needed to control a servo or stepper motor doesn't really change as you scale up the motor. The hardware changes, but the way the hardware is controlled is similar.

I'm still concerned that using multiple PINGs will cause false echos. At under 18 inches, an IR sensor would be much more useful and there's no problem with flooding the surrounding space with modulated IR.

The GPS should work fine. There have been postings by others about using the Propeller with a GPS receiver.

Again, other than the video, what sensors do you have that have high data rates? For some of the sensors, your host processor may only be interested in changes to the environment and it doesn't have to be notified otherwise. For example, why tell the host that nothing is visible to the PINGs (or IR sensors)? That's an example of efficiently managing communications bandwidth.

AIman

Mike,

I really appreciate this conversation it has been most helpful and when the project is done I have no problem sharing the Propeller code. The LISP program is part of a project my company is doing so that is a different story.

The reason for LISP is because of the decision making process required to move the servos ect. and also because of its ability to·access a program while it running. I would go into more but not alot of people know common LISP - which in my mind is a shame because it is very useful. In fact a really good book to start with can be found on line - for free - Common Lisp: A Gentle Introduction to Symbolic Computation. It takes people with no programming experience through the basics of how functions work and then goes on from there to be applicable to every one. After this book Practical Common LISP is a good follow up and is also available online for free. From there go to Amazon and look at the advanced books, there are several that are pretty good.

My reasoning for going with Sonar over IR is because of light changes. The sonar are not affected by light but IR can be. Right now the sonar are arranged 60 degrees apart if you look at it from the point of view of a compass. I would prefer IR because it is easier to use and cheaper, but the light enviroment will be changing go from day light to indoor light within a few seconds. That makes me edgey when thinking of affects·to IR. IR can always be tried, the components will definatly be used elsewhere on the project.

The GPS module is the one Parallax sells except that the altimeter readings will be set based off aviation altimeter readings for the day, the time will be based off milliseconds and the distance traveled will be crosschecked based on a·few other factors.

The controllers mentioned will probably be more useful then the drivers I am looking at now because of propeller support. I am also looking at the CMU camera software as a concept. There are a few places online that support robot vision software - one for free - and most of these are good for small cameras to identify color but not much esle. Because of needing a much more complex object identification program it is a way to start with a concept, but not even close to the end result. Also I don't know if they would support a video camera, but it looks like they might.

Heres the link to the free robot vision program http://www.roborealm.com/·

Mike Green

You've got a pretty big project. I understand the Sonar vs. IR issues. With the 60 degree spacing, you'll probably not have problems, but you might have the Propeller do a 2 phase scan before reporting to the host by looking at the echo return times and repeating individually just those that report times in the interest range (18" or less). It should only add a few ms to the delay.

LISP is great for complex systems like this. I've tended to use Scheme rather than Common Lisp because it can be used on small computers and it's very fast when interpreted. There's a Scheme implementation for the Palm for example. It would be quite powerful to have a Scheme interpreter for the Propeller, but there would need to be an order of magnitude more fast memory at least.

Thanks for the link to RoboRealm.

AIman

Based on our conversation this is what is intended to happen.

The Propeller chips will have all 8 cogs dedicated as follows

Prop 1

Cog 1: Solenoid 1

Cog2: Solenoid 2

Cog3: GPS

Cog4: Stepper motor 1

Cog5: Solenoid 3

Cog6: Stepper motor 2

Cog7: Stepper motor 3

Cog8: Solenoid 4





Prop 2

Cog1: Sonar Left side if <= 2 feet return value to host

Cog2: Sonar Front·if <= 2 feet return value to host

Cog3: Sonar Right side if <= 2 feet return value to host

Cog4: Sonar Back if <= 2 feet return value to host

Cog5: Mid Range Scanner Left side if >2 and <=35 feet return value to host

Cog6: Mid Range Scanner Right side if >2 and <=35 feet return value to host

Cog7: Long Rang Scanner Left side if·>·30 feet return value to host

Cog8: Long Rang Scanner Right side if >·30 feet return value to host



LISP to Prop will be interesting, never tried that before...



Thanks again for all the input.

Mike Green

Given your list of "responsibilities", I think you are vastly underrating the capabilities of the Propeller's cogs. For example, one cog could easily handle the 4 PINGs you've assigned to cogs 1 through 4 and probably have time to handle all the scanners as well (even though I'm not familiar with the scanners). One cog could easily handle all the steppers and probably have more than enough time to do the solenoids too. The GPS (if it uses a serial interface) could be handled by two cogs (one for the serial driver and one for interpreting/converting the data). The LISP to Prop interface would probably be handled by two cogs (one for the serial driver and one to manage the message stream). That's only 6 out of 8 cogs in one Propeller!

A single cog using SPIN can easily handle at least a 19.2KBps half duplex serial bitstream, doing accurate bit timing, unpacking bytes into bits, etc. Alternatively, a single cog using SPIN can easily control 4 conventional servos with each servo action consisting of a new position setting and time to achieve that setting (for slow movements). Using assembly language, a single cog can implement a full duplex serial channel at in excess of 1MBps or control 32 servos (more if there were more I/O pins).

AIman

Your probably right in my underestimating the cogs. I am used to a BS2·and those tend to be a bit slow and dedicating one function to a BS2 if very helpful when speed is needed. For everything listed below the speed must be 1/10 of a second or faster.

Cog1: Solenoids 1, 2, 3, 4 and Stepper motors 1, 2, 3
Cog2: Sonar 1, 2, 3, 4; Midrange 1, 2, 3, 4; longrange 1, 2, 3, 4
Cog3: GPS
Cog4: GPS
Cog5: LISP interface
Cog6: LISP interface
Cog7: Servos
Cog8: Empty

Did I get that right?


Could a Cog handle a feed from a live video camera on top of all this?
It would need to always feed to LISP.

If so Cog·8 would be a live video camera.

Most of the time the solenoids will be acting one at a time with a limited·5 seconds or so of two at a time twice during the program.

Only one set of sensors will be used·at·a time, so your right I could run all the sensors off one cog.

The Servo·and GPS will be used constantly as will the LISP interface.

Looking back at it I can see that I really did underestimate the capabilities.

Mike Green

AIman,
There has been some discussion around video input. Part of the problem is that the Propeller just really isn't fast enough to do the processing. For video output, there's special hardware built-in to the Propeller that takes two 32 bit words (one with 2 bit pixels and one with color info) and generates the video bitstream. Part of the problem with video input is finding the memory to store it since the shared HUB memory is only 32K and some of that is needed for other things. One forum member (Phil Pilgrim) has been working on a PropCam using a black and white CCD camera which provides the data in digital form and with limited resolution <http://forums.parallax.com/forums/default.aspx?f=25&m=131097>. It might be possible for a Propeller to use maybe 4 cogs and some external hardware to capture small areas of video frames with a cog doing a single scan line, waiting from the horizontal sync pulse to the start of the subframe, then storing flash ADC samples in a cog buffer until the end of the subframe. The next cog would handle the next scan line. By the 5th line, the first cog should be able to have dumped its buffer into HUB memory, maybe doing a little compression, and be ready to do another scan line. Without a lot of extra hardware, this would involve luminance only with no color information.

Anyway you look at it, standard resolution full motion color video input takes a bunch of fast hardware to handle and the Propeller really isn't up to it.

AIman

Thanks. It looks like I will have to write something in LISP.