Rosetta Code:Village Pump/Suggest a programming task: Difference between revisions
Rosetta Code:Village Pump/Suggest a programming task (view source)
Revision as of 05:40, 19 May 2009
, 15 years ago→Stateful behavior simulation: Set as project level, broke it into parts.
m (→Games) |
(→Stateful behavior simulation: Set as project level, broke it into parts.) |
||
Line 65:
:: probably means some thing like this <nowiki>http://ansuz.sooke.bc.ca/software/molester/molester</nowiki>. To make it suitable for rc the restrictions need to be spelt out - i.e. fixing the protocol and discovery mechanisms [[User:Rahul|Rahul]] 20:24, 7 October 2008 (UTC)
===implement a table-based native code (macro?) assembler in various HLLs===
===Stateful behavior simulation===
Demonstrate discrete event simulation and stateful behaviour by simulating a simple pick-and-place or storage/retrieval system robot. The robot would be given commands to retrieve from location A and place into location B. The robot would in turn command its 4 motors in sequence in order to accomplish the task. The amount of time that a motor runs would be dependant on the distance required to move. A scheduler would be set up to generate callback events to the motors at proper times to indicate
their motion was complete. The complete specification of this task would be somewhat involved. --[[User:Rldrenth|Rldrenth]] 18:09, 20 January 2009 (UTC)
:This needs to be simplified/clarified from requiring "four motors" to having three commands, "set velocity forward/back", "no-op" and "claw open/close".
:Subsequently, it can be divided into four parts:
# Call a function at a constant interval
# Create a function which reads from a primary queue containing simple commands and a secondary queue containing complex commands, processing exactly one of these commands, and then calls the state update function.
# Create a function that converts a complex command "starting from x1, pick up at x2 and drop at x3" to one of the three simple commands
# Create a function that updates the state (velocity and position) based on the currently executing command.
In the interest of simplicity, it can be assumed that the program may terminate once the secondary queue is empty, that the robot has a constant velocity either forward or backward, and that the velocity and position values at termination are irrelevant. --[[User:Short Circuit|Short Circuit]] 05:40, 19 May 2009 (UTC)
=Recently Completed=
| |||