Software > Software
Distributed algorithms
obiwanjacobi:
Yep cooperative multi tasking was what I had in mind for the main MCU. You can keep it (overhead for tasking) very lean. Unfortunately I haven't bumped into a good C++ library yet... so I guess I will have to roll my own.
Another option I have considered is using a multi-core processor. I read some on the Propeller Parallax and that looks very promising. That way you can have really separate task that run truly parallel.
Have true multi-threading also introduces some synchronization and locking issues but I was hoping to adopt a message based paradigm and avoid shared state (that should take the pain out of most issues).
What do you guys think?
Jon_Thompson:
To be frank, I think you're over-complicating things, but my overriding philosophy is always to get the most work out of the least computing power.
obiwanjacobi:
Yes, I tend to do that ;D
I usually let my 'imagination' run wild in the design phase to end up with the 'perfect picture'.
But when building time comes I simplify it and only build what I need - but following the design of my perfect picture as much as possible/sensible.
I know that once you start building you will get new ideas - or discard old ideas - things will change. That is evolution and that is part of the fun.
My questions here are more geared toward 'what experience of others who've been there can I use'.
Thanx for your comments.
jwatte:
In general, for safety, you want a "dead man's" system. Two nodes communicating will exchange data at a certain rate, and when one end has missed its time slot by more than X time, assume that that node is dead until you find out otherwise.
Thus, for example, a node driving a motor controller should stop the motors if it goes for 100 milliseconds without getting any new commands from the higher-order function that decides on desired motor speeds.
If you use a network like CAN or I2C, they already have built-in functions for addressing particular nodes. You just assign node IDs ("front left leg == 5") and go.
Duane Degn:
--- Quote from: obiwanjacobi on April 24, 2013, 05:51:43 AM ---Another option I have considered is using a multi-core processor. I read some on the Propeller Parallax and that looks very promising. That way you can have really separate task that run truly parallel.
--- End quote ---
I was going to suggest the Propeller. The multiple processors are a great fit for lots of robotic projects.
For example, I used the Propeller in my Mecanum wheeled Rover 5. One processor (cog) is dedicated to reading the four quadrature encoders (without causing insane numbers of interrupts(or any for that matter)). Another cog produces the four PWM signals (a single cog can produce many more than just the four). Another cog used used as a UART (a single cog can easily be used to provide four UARTs).
Breaking the tasks down into independent cogs keeps the main loop nice and clean. You don't have to worry about interrupts messing up the timing of other parts of the code.
Post #85 of this thread has a fun (IMO) video of the robot moving around.
http://forums.parallax.com/showthread.php/130797-Mecanum-Wheeled-Robot-with-Machine-Vision?p=1166320&viewfull=1#post1166320
I've listed a bunch of my Propeller projects in post #2 of this thread:
http://forums.parallax.com/showthread.php/135706-Index-Test?p=1049895&viewfull=1#post1049895
I'll force myself to stop here. I often get kind of carried away when I start talking about the Propeller. I'm a really big fan of the chip.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version