Cogs and Com Between 2 Props
Chris The Carpenter
Posts: 18
Howdy again folks. I got such great help with my first question, I thought I would try for a second. I fixed my first problem, by the way, it turned out to be one of my Arduino slaves. --Figures it would be the Arduino...
I am adding a second prop to Walter the robot and I seek advice on the most efficient way of doing it. Consider one chip to be the "drive" chip and would do sonar, encoders, motor driver stuff and some bluetooth to the laptop. The other would be a "personality" chip and would take care of the audio, head moves etc. These chips would not really be in a master/slave set-up but instead, like two co-workers who are both watching the same screen giving them the instructions. (And they can both update the screen)
So far I figure some good ol' serial is the way to go. I would have (2) arrays on each side --> bytes_to_send[10] and bytes_Received[10]. I would set up a dedicated cog on each end to constantly update these arrays. Basically, "Hey, here's what I got, what do you got?" from one chip to the other. From there, the main loops can do whatever they want with the data in these arrays.
I obviously want to use a pretty fast baud rate here. This eliminates "simple_serial". If I go to FullDuplex, I would have to use 2 cogs, one for the serial and one to watch the serial and update the arrays. Another option is to do some work on the FullDuplexSerial object itself and put my "serial watcher/ array updater" inside of that cog/object.
--or--
I could not be going at this the right way at all...
I welcome any thoughts.
I am adding a second prop to Walter the robot and I seek advice on the most efficient way of doing it. Consider one chip to be the "drive" chip and would do sonar, encoders, motor driver stuff and some bluetooth to the laptop. The other would be a "personality" chip and would take care of the audio, head moves etc. These chips would not really be in a master/slave set-up but instead, like two co-workers who are both watching the same screen giving them the instructions. (And they can both update the screen)
So far I figure some good ol' serial is the way to go. I would have (2) arrays on each side --> bytes_to_send[10] and bytes_Received[10]. I would set up a dedicated cog on each end to constantly update these arrays. Basically, "Hey, here's what I got, what do you got?" from one chip to the other. From there, the main loops can do whatever they want with the data in these arrays.
I obviously want to use a pretty fast baud rate here. This eliminates "simple_serial". If I go to FullDuplex, I would have to use 2 cogs, one for the serial and one to watch the serial and update the arrays. Another option is to do some work on the FullDuplexSerial object itself and put my "serial watcher/ array updater" inside of that cog/object.
--or--
I could not be going at this the right way at all...
I welcome any thoughts.
Comments
The object Mike is referring to is Tim Moore's pcFullDuplexSerial4FC. It's a great object.
I like to think I've made it even better. My rearranging the buffers and variables, I doubled the rx buffer from 64 bytes to 128 bytes at the cost of increasing the object size by a few (3) longs.
I've modified Tim's object several other ways as well. Here's the thread.
I have a version with one of the tx buffers increased from 16 bytes to 512 bytes (it shouldn't be hard to make any buffer any size one wanted).
One of the versions I use with XBee communication. Each transmission includes a counter so the receiving XBee knows if it's receiving new information or if the transmission is a duplicate transmission. The receiving XBee acknowledges the transmission by sending an acknowledge character with the counter value. The XBee that send the original transmission doesn't have to check through its rx buffer for the acknowledgment since the serial driver watches for the acknowledgments and sets an appropriate flag when it's received. (I think I explained it better in the other thread.)
Anyway there are several examples of modifying the serial driver to meet specific needs. Maybe one of the version will be helpful to you.
I have several Prop to Prop communication projects. I'm in the middle or rewriting most of my code to take advantage of these various modified serial objects. (Plus, I think I have a much better understanding of how the Propeller works now and I think I can improve these projects with a code rewrite.)
I'm always willing to share my code (though it is pretty rough around the edges right now). Let me know if you'd like to see some other examples besides what I've posted in the above mentioned thread.
BTW, I've enjoyed watching your Walter videos at LMR. Seeing Walter wander around had made me want to get back to some robot projects I had on a "back burner" for a while. I'm glad to see the Propeller gaining in acceptance at LMR.
Duane
(For those who might not know, LMR stands for Let's Make Robots.)
I adore the idea of more than one serial line within one object and one cog --that actually solves a couple problems for me.
I can't believe I have already grown out of 8 cogs already. Being a picaxe/arduino convert, I have found that cogs (especially on a hobby robot) are like crack --you can't get enough. Most recently, I have been working on a wiicamera/laser range finder. Gareth (the project of the week) is a good friend of mine and much inspiration for the project. It is working so well, and has paired so well with some software I had written in Processing, that I want to start using it for navigation and mapping (over and above the regular sonar). This put me over the top in terms of cogs --and I/O pins for that matter-- and well, you know the rest.
Here are the first tests. As I say in the video, everything is incorrect, not adjusted and using very chunky code. And it is wicked late and I sound stoned in the video due to the exhaustion. That being said, the thing friggin' works!!
http://www.youtube.com/watch?v=7T6lj5QZUe0
PJ, I'm seeing a pattern here.
@Chis the Carpenter - looks like a cool project.
Yes, the cogs make a great way to get things done quickly without interactive problems. You can of course save some cost on the prop circuits by using the first to download the second and saving the eeprom on the second including the potential to reuse those unused eeprom pins. I can see the requirement for the Robot to have lots of cogs to simplify the code. Seems you may need quite a few props here as time goes by
On a daily basis I ask myself, "how in the [flipping] world did I used to do this?" in terms of multiple cogs. Take the sonar for example... The sonar sits in a nice tidy little cog, looping away and doing one thing [wicked] fast and well. When the drive/navigation routine needs some info on sonar readings, it already has them! The numbers are always there and whenever you grab for them, you will always get the most recently updated data. Same with the X-bee loop. It just sits there, waits for any [data] from the transmitter, and updates arrays. [Heck], you don't even have to call on them, [for cryin' out loud]! The variables are just "taken care of" and I simply don't have to give it a [hoot] of thought beyond that.
How much time and uC thinkin' power is wasted on endless subroutines just to do mundane tasks like checking the [darn] sonar, when doing it the "old" way...
P.s. Did I get the swearing joke right? I mean, the [ ]'s... I'm sorta new here... I laughed in my head as I typed it. Oh, c'mon... the [data] one --C'mon that's funny. Right? Shoulda left while I was ahead...
However, once you grab onto the idea, the question is how did I program before! This way is so neat.
I know how buffers work in general. I'm open minded to new ideas. But from the three lines you wrote I can't get my head around it how this works for two props communicating with each other.
Would you mind attaching a demo-code and explaining with more details how it works?
best regards
Stefan
I'd like to second Stefan's request.
Thanks,
Duane