Shop OBEX P1 Docs P2 Docs Learn Events
spin setup help!! — Parallax Forums

spin setup help!!

LuckyLucky Posts: 98
edited 2010-01-05 21:11 in Propeller 1
Say I had this robot that had distance sensors, line sensors, motors for wheels, motors for its arm, and a RF receiver module. So what I want the propeller to do is to activate the robot once it receives an rf signal. then the propeller would simultaneously monitor the sensors, sending data back·to the navigation part of program, moving around and using its arm. So would I have a top object that waited for a rf signal, then·launched all these different objects(navigation, motorWheels, motorArm, Sensor) into different cogs? I want the robot·to go about moving and monitoring sensor simultaneously, with the sensor objects sending data to the navigation and motorArm objects. How do I organize this mess? Do I have the wrong idea of how I should use objects and methods to accomplish this?

Comments

  • ElectricAyeElectricAye Posts: 4,561
    edited 2010-01-05 02:42
    In general, I would say you have a decent chance of getting the Propeller to do the kinds of things you want to do. I don't know if it can do everything you want, but the only way to find out is to get started.

    You might want to read the section on page 67, etc of the Propeller Education Kit manual, which talks about Methods and Cogs. In fact, you might want to read the entire manual. It's very interesting.

    www.parallax.com/Portals/0/Downloads/docs/prod/prop/PELabsFunBook-v1.1.pdf

    hope that helps get you started,
    Mark
    smile.gif
  • Mike GreenMike Green Posts: 23,101
    edited 2010-01-05 02:56
    Try not to get too confused in mixing up cogs and objects.

    A Propeller's cogs are just multiple identical computers that share stuff like I/O pins and hub memory. You can use just one cog for everything if that makes sense or you can run different "programs" on different cogs or the same "program" on more than one cog if that makes sense.

    Similarly, objects are just one particular way to package up parts of a program, usually something that you'd treat as a library routine or package of library routines on a PC. An object can make use of a cog to handle part of the "library routine"'s processing or it may not use a extra cog at all, whatever makes sense for the task at hand. The main thing is that an object only presents some of its names to the outside world, in particular its public methods and its named constants. All the other names are internal to the object only.

    A method is just a subroutine (procedure or function). That's all. It can have parameters. It can have local variables. It can return a value.
  • LuckyLucky Posts: 98
    edited 2010-01-05 03:23
    Can you use the coginit command in an object besides the top object?

    ··· If you can use coginit in child objects, then couldn't I just have like a GO method in every object to launch the rest of the code in the object into another cog? So, the parent object could say like DistanceSensor.Go, LineSensor.Go, Navigation.Go and so on.Then the Go routine in each object would launch the rest of the methods in the object into another cog


    Post Edited (luckyshooter353) : 1/5/2010 3:47:12 AM GMT
  • ElectricAyeElectricAye Posts: 4,561
    edited 2010-01-05 05:12
    luckyshooter353 said...
    Can you use the coginit command in an object besides the top object?


    If you can use coginit in child objects, then couldn't I just have like a GO method in every object to launch the rest of the code in the object into another cog? So, the parent object could say like DistanceSensor.Go, LineSensor.Go, Navigation.Go and so on.Then the Go routine in each object would launch the rest of the methods in the object into another cog

    I don't really know how to answer that question, but let me say this: I think it's best to use the cognew command instead of coginit, and thereby let the Propeller keep track of which cogs are doing what.
    Of course, you don't have an infinite number of cogs to work with and some objects tend to be cog hogs, so you might have to write the Main program with the knowledge that some Methods are going to get shut down as new Methods are called up. You can store information in global variables, etc. so it's possible to stop and start objects that pick up where they left off in processing data (so long as the program can handle the gaps in sensor data, etc.).

    hope that helps a bit,
    smile.gif
  • StefanL38StefanL38 Posts: 2,292
    edited 2010-01-05 08:00
    that's the way how objects that need an own cog are working.

    There is a convention about the name to do this. All objects should use the name "Start" instead of "go" or "init" or whatever.

    As long as some part of a code doesn't really need to run independent from others you can put calls to methods in one and the same loop.

    F.e. CheckBatteryvoltage, CheckMotortemperature, UpdateLCD are things that change slowly. So if you call them all in the same loop the executiontime of the loop will be a few milliseconds
    and that is sure fast enough for these things.

    Remember you got 8 cogs not 800. So you should think about what could be done with one cog and what REALLY requires its own cog.

    best regards

    Stefan
  • LuckyLucky Posts: 98
    edited 2010-01-05 21:11
    Thank you for all the replies. I think I have this mess figured out
Sign In or Register to comment.