Next large robot

1181920212224»

Comments

  • DiverBob wrote: »
    ....

    I can set up a dedicated cog just for sending data back to the master over a single wire that connects to all the legs. This is a trickier process than the master sending out to the individual legs as all 6 legs could transmit back to the master and interfere with each other. ...........
    So what I’m trying to do is figure out if this is the best way to approach this problem or if there is a better way I haven’t seen yet. I hope that explains the process better, I kind of clouded the issue earlier when talking about some of the difficulties running parallel processes.

    This type of communication has been done many times in the past using one of several protocols. Typically it goes like this:

    A single half duplex line goes from the master to all the slaves.
    All slaves listen for a command addressed to them from the master.
    When a slave receives a command it sends back data and/or acknowledgement to the slave and then goes back to listening.

    Most commonly used protocol is probably csma/cd, which is the method used by ethernet.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • kwinn wrote: »
    ....
    This type of communication has been done many times in the past using one of several protocols. Typically it goes like this:

    A single half duplex line goes from the master to all the slaves.
    All slaves listen for a command addressed to them from the master.
    When a slave receives a command it sends back data and/or acknowledgement to the slave and then goes back to listening.

    Most commonly used protocol is probably csma/cd, which is the method used by ethernet.
    I misspoke earlier using the term ‘single wire’. What I meant was daisy-chaining all the leg computers to a common pin on the master for a dedicated transmit line from the master to each leg. This line is just for sending leg movement instructions from the master to the leg controllers from the main program loop. I didn’t want to add any more code overhead to receive data on the main loop due to the the amount of floating point math calculations it was already doing for figuring out leg movement. I have already seen some evidence that the code might be too slow as I add calculations for additional legs so I’m trying not to overburden the main loop any more than necessary.
    I’m using a separate wire to daisy-chain as a dedicated line for feedback from the leg to master. This is where possible data interference can occur due to all 6 legs having data to send to the master over this line.
    I’m using a 4 port serial object so I can dedicate a new port on a new cog for this additional communications link. Having a dedicated line from the master to the legs for transmission simplifies the coding on the master side of things, it just has to have a loop where it requests data from a specific leg and the specific leg sends back the information. The other legs just have to listen for when a command is applicable to them.
    I did a lot of reading last night on prop to prop communications, there are a lot of options out there! The setup I’m looking at implementing has 2 separate ports on two cogs transmitting from the master with a separate port recieving data on the master for leg feedback. The feedback loop is required to make this a closed loop system so that if for some reason a leg can not complete a requested movement then the master can perform some action. Otherwise it could lead to major mechanical breakage or the robot falling over. Plus I have some additional sensors to add to the legs In the future that need to send data back also.
    I’m going to start programming this in today, nothing else planned for distractions so hopefully I can get some momentum going on this and get it into testing.

    Bob
  • If all the lines from the leg computers are going to a single pin on the master it is essentially the same as a single wire connection since all the leg computers are receiving the data intended for any one of the legs. Half duplex handles that easily.

    Master sends out a command with the address of the slave as one of the bytes (usually the first byte) in the message.
    Slave responds with data/acknowledgement/or whatever is required to master.

    Commonly used this on automation systems. Typically I use address 0 as master and 1 - 255 as slaves, although I have never had a system with more than a dozen or so slaves.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • there is a nice serial object from @Beau Schwabe. The concept behind it is to daisy chain all Propeller together in a ring, one COG for input one COG for output to the next propeller.

    Then you dedicate a HUB ram area as cmd/response buffer and send this buffer from Prop to Prop continuously around and around. Each Prop receives the buffer and sends it to the next until it comes back to the first one.

    Now you can use the same mailbox method used normally to talk from one cog to another on the same chip across multiple chips.

    This is dead simple and does require 2 pins and 2 cogs per propeller. The whole communication runs constantly in the background just moving the buffer around and you just need to dedicate certain areas of the buffer to certain Propellers, say the first 10 longs for the first leg, the next 10 longs for the second leg and so each Propeller can read its commands and write its responses simply in its dedicated buffer. by writing /reading its own HUB ram.

    The only problem is that when one Propeller dies the complete communication stops. But in your case that might be OK because if one leg controller dies the rest of the robot should not move any further.

    I think it was called High-Speed serial or something alike and should be in the OBEX.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Beau’s serial object is nice but I only have one open cog on the leg controllers and no way to free up another one. His solution is elegant and would be great if I had the cogs....
    Kwinn - I didn’t conceptualize what you meant until this posting. You are correct, I could just use a single daisy-chained wire from the master to each leg controller for both transmit and reception. That simplifies wiring with no other changes to the code.
    Using the 4 port serial object, I started a 3rd port on the leg software. I put in a simple repeat loop to check for an input from the master (example: $,6) for that leg and then output the feedback data followed by a unique end character (#). I didn’t put the master computer in the mix yet but did some checking using my debugging connection to simulate master requests. Most of the code is working fine and the expected feedback information is being generated to the screen. I ran into a bit of trouble using the debug console to send motor commands and feedback commands over the same line (since I have 2 separate processes looking for input and I used the same schema ($,leg#)) to call both - it’s only a problem debugging because normally these would be looking at 2 different master computer outputs, not a single terminal providing input to both). That caused some interesting results. I will change the ‘$’ to another unique character (maybe use % instead) to avoid this for future troubleshooting!
Sign In or Register to comment.