If I network 2 or more basic stamps together, for example to use my old bs2 as a slave with my bs2p as the master. Will this in effect, provide me with more overall processing power if I simply use the slave to process and send the results for a couple sensors to my master bs2p?

Has anyone network basic stamps together for this purpose. Some of us just upgraded to a bs2p and although the Propeller is great!, I do not wish to invest in a new processer and board at this time but would like to get the best out of what I have now.

Jim

Views: 614

Reply to This

Replies to This Discussion

It depends on what you're using each for. If, for instance, one Stamp is running an IMU and handling stabilization, while another runs GPS and navigation, the communications overhead between them wouldn't be too large. But anything more complicated than that risks getting into some very complicated communications and queuing programming. In general, what you describe can certainly work, but at a certain point you may ask yourself whether it was worth the bother considering the complexity.

Here's something that comes close to what you describe: http://www.thebacons.info/colin/robocube_v2/index_controller.htm
I did a BASIC Stamp network a few years ago. Not really worth it. I have an extra BS I am trying to figure out what to do with too. I think I am going to just break down and try the Propeller, since it has a lot more horse power in a smaller footprint than 2 Stamps.

Here are a couple links to possibly help, though;
Link
Link
only in a parrellel proccesing sceem . i would not try to pass sensor data from one stamp to another for processing but you could easily have one stamp controll the state of another ie one stamp could be used for stabilization / rc pass through and it could turn on and off another stamp that does navigation.
Sounds to me like the propeller is a better way to go. However, my main concern I guess is lacking the ability to read more inputs from the parallax servo controller. I wish to have more sensor input and using PULSIN with the standard input pins on the stamp works, I am running low on input pins with the advent of a gps, lcd panel, receiver input for 6 channels, and future concerns.

Have you had luck reading in sensor data when a sensor such as the GPS and LCD is connected to the servo controller? What type of preambles do you need to send in order to read the response using SERIN? The instructions are clear for returning a servo position but not for other components.
James,

Can you explain a bit more why you want to use the servo controller for that? It's controlled by a single serial port, and normally each sensor or external device like the LCD would get its own serial port/pin. Not sure how to multiplex several devices on the same serial port, although someone else may know.

Is it that you've literally running out of Stamp pins (ie, you're using all 16 available IO pins)? In that case, you just want to switch the the 40-pin version of the Stamp, which has 32 I/O pins,.
http://parallax.com/Store/Microcontrollers/BASICStampModules/tabid/...


FWIW, the Propeller has 31 I/O pins.
I still have a few PIN's left so I am not that bad off yet, however, I will have to get a carrier board to allow solid 3 pin connectors to support all the 3-wire extensions I am using to feed and output data to the stamp. The development board is not something I wish to fly as I could see wires popping out. Have you or anyone else wired up and soldered the components to a carrier board? Parallax seems to have three that show promise.
I guess with the feedback I am reading. the only thing I can do with my bs2 stamp is use it in a future endeavor. Perhaps to act as the receiving end of a telemetry system.

Speaking of telemetry, has anyone else done this? :)
I am not completely knowledgeable about the available peripherals are available for Stamps and how much CPU power they each consume. Here are some general communication preferences I have for most of my embedded processor projects.
If you wish to have one master and all the other processors as slaves then usually SPI is a good choice. The signal count is somewhat low, with Din Dout and Clk to all the devices plus a chip select for each of the slaves. I tend to like SPI because it is very fast, usually close to the processor's clock speed. It is also very easy to debug on an oscilloscope compared to some of the 2 wire communication protocols. When things go really bad you can usually get aways with manually bit-banging the protocol to try and debug. There is no need to deal with a communication addressing scheme since you handle that in hardware with the CS signals.
One under-rated multi-drop communication protocol is RS-485. This can be implemented by using a RS-485 driver IC on a standard UART instead of the RS-232 driver you usually use for serial. I believe up to 32 devices can be networked on this 2(half-duplex) or 4(full) wire bus. The signals are also rated for wire lengths greater then 1 Kilometer and can be as fast as 10Mb/s at shorter lengths. The problem here is that you will need to come up with your own addressing scheme between the master and slave devices.
Another good one is I2C and this only requires that all the processors be connected on the same 2 wire bus. This is slower then SPI, usually between 100KHz-400KHz, and also can be tricky to configure if there is no available driver. The configuration will need to differ between your slaves and master device. Most processors will now also support multi-mode I2C. This is really neat because it allows all the devices to act as master devices and then they will switch back to slave mode when they are idle on the bus. The addressing scheme is also built into the I2C peripheral so there is no additional coding required.
The CAN protocol has a lot of features that might be necessary if you are want to assign priorities to different sensors but it is overkill and probably not available on Stamps. Cars use these networks so crash sensors can take priority and quickly deploy airbags. CAN is available for most low end processor families now.

This is my first visit to this site and I am absolutely amazed that these UAV projects are all possible on the Stamp processor. The BASIC Stamp is a great teaching tool for embedded systems and also can be used for easily designing a simple control project but UAVs?!? I do not at all intend to insult anyone here and I am truly impressed with your projects. It just seems like most of you have mastered all the Stamp has to offer for processing power and could definitely benefit from switching to a higher performance part. What is they big attraction that pulls all hobbiests to the BASIC Stamp? I am not trying to criticize or mock their product or your design choice. I see this same situation on hobbiest's projects all over the web and I just do not really understand why? I have not dug into the Propeller chip but it looks like a pretty neat part and dwarfs the Stamp for processing power. There are huge advances in embedded computing technologies that are being overlooked by such a large portion of the "part-time" embedded designer community.

Why not choose a product you can develop in C instead of the proprietary languages offered by Parallax. I am an Embedded Engineer so my opinions might be skewed but I think embedded C is not a huge jump in programming skill compared to BASIC used by Stamps. Writing C applications for a PC is a whole different story but embedded apps can be very simple. Once you get used to embedded C you then have the ability to switch to different platforms without having to learn a new language. It seems like you probably would have made that platform jump already if some other company made a powerful processor with the same instruction set that the Stamp uses.

For high performance embedded controllers, my favorite platform is NetBurner. They has a great 150MHz 32-bit module with a $99 dollar dev kit that includes everything you need. One of the company's founders, Paul Breed, is using this product as the main controller for his X-Prize Lunar Lander project. Paul is first getting the controller to function as an autopilot on his RC helicopter. Check out the progress on this heli-UAV and lunar lander here: http://unreasonablerocket.blogspot.com/
Paul has posted some servo controller code on the NetBurner yahoo group and I wouldn't be surprised if he releases all of the source and schematics for this project when he completes it .

The NetBurner development environment is easy to get started and comes with an RTOS, file system for flash cards, easy to use peripheral drivers (UART, I2Cmulti, CAN, SPI, Ethernet), network stack with most of the major Internet protocols, tons of examples and ALL the source code. Another great feature is that code updates and debugging is all done over Ethernet which is extremely fast. You can really get right into coding your project after about 20 minutes of looking through the examples and application notes. There is even a non-network, 66MHz, 40-pin dip product which will blow away any 8-bit device in the same form factor. A Stamp BS2p can process 12,000 instructions per second and the MOD5270 that is included in the low cost kit can process over 140,000,000 instructions per second, 60,000,000 for the MOD5213 in the DIP package. Parallax's low-cost educational kit, which comes with a standard BS2, is the same price as either the MOD5270 dev-kit or MOD5213 dev-kit. The Parallax PINK Ethernet kit is also powered off a NetBurner or is it the other way around?
Thanks for that very helpful response and observations. Three quick responses:

1) The point of this site is to make UAVs as cheap and easy as possible. Basic Stamps are the easiest way to get into embedded programming, so we designed an autopilot that could run on that alone. What that meant is that it's not a full autopilot-- it's a "navigation-only" autopilot. Another system (in this case the FMA Co-Pilot) takes care of stabilization. This, we've found, is the easiest way to get started in UAVs and can make a very capable autopilot that can control a lot of other aircraft functionality, from cameras to datalogging. There's a lot to be said for easy!

2) Many of us here have indeed moved to more powerful chips and programming language when we start adding IMUs. The Lego Mindstorms autopilot (which is now a navigation-only autopilot, but a full navigation+stabilization autopilot is in the works) is based on an ARM7 chip. We have projects on the Propeller and Arduino chips. We're using a PIC processor on the blimp UAV. And there are others who are using Gumstix.

3) I agree that C is a better language for the more math and data-intensive advanced autopilots, but we tend to let the hardware dictate the language. We use RobotC for the Mindstorms project, Spin and Assembly for the Propeller projects, Wiring for the Arduino, etc.

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service