Group items tagged

It is straightforward to implement an interpreter-like interface, where user commands are transparently compiled, downloaded, and executed.

The Cricket virtual machine is burned into the PIC microprocessor's internal ROM

The user's code resides in a serial EEPROM

Built-in infrared communications routines include a protocol for reading and writing to this external EEPROM, and for asking the virtual machine to begin execution of byte codes already loaded into the EEPROM.

Users write programs for the Cricket in Cricket Logo, a dialect of Logo specialized for the Cricket virtual machine. Essentially, there is a one-to-one mapping between statements in Cricket Logo and primitive functions built into the virtual machine. This makes the implementation of the compiler far simpler than typical compilers.

The infrared protocol includes the following capabilities: Check that a Cricket is present and ready for other commands. Write a byte to the Cricket's EEPROM. Read a byte from the Cricket's memory. Begin program execution from a particular memory address.

we have found that a debugger is not necessary because of the interactive and incremental style of project development that occurs when using the Cricket.

The compiler includes an interactive mode—a text window where user expressions are compiled, downloaded, and executed in one step when the user presses the return key. A portion of the Cricket's memory is set aside for these dynamic programs.

User-level primitive functions compile to one, two, or three bytes of object code for the Cricket virtual machine.

The Cricket virtual machine has two process threads: a foreground process and a background daemon. In most Cricket programs, the foreground thread handles all the work, but for some tasks, the background daemon is valuable. For example, the background daemon can be used to instigate a periodic activity, or take action when some event occurs.

There are hardware-specific primitives for interacting with on-board Cricket hardware. Motor commands set state (on or off), direction, and power levels for each of the two integrated motor drivers. Analog sensor primitives (sensora and sensorb) return a value (0 to 255) for each of the two voltage inputs. These inputs also may be interpreted as digital values using the switcha and switchb primitives. There is a pair of primitive functions for generating tones on the piezo beeper: beep and note, the latter taking pitch and duration arguments.

there is a background millisecond timer that is updated every four milliseconds

One foreground thread plus one background daemon Daemon fires when provided Boolean expression makes false-to-true transition

To effectively use your Sharp IR Range Finder, you must have a voltage output versus distance chart to reference from.

One major issue with the Sharp IR Range Finder and that is going below the minimum sensor range. This is when an object is so close the sensor cannot get an accurate reading, and it tells your robot that a really close object is really far.

Another issue is the high narrowness of the IR beam. In reading sharp details and getting high accuracy, a thin beam is ideal. But the problem with a thin beam is that if it is not pointed exactly at the object, the object is therefore invisible.

A more advanced use for the Sharp IR Range Finder is to do mapping. To do this, you need at least one Range Finder, and at least one non-modified servo.

The sharp IR can be used as a quick and easy front non-contact robot bumper on your robot. Just place two IR devices in front of your robot and cross beams as shown. Ideally you would perfer to use rangers that have wider beams. Note: A single sonar can do this job just as well.

For example, a box in front of your robot might appear like this: 0 0 0 0 0 106 120 124 121 109 0 0 0 0 0

Eventually, we got to the point where we don’t know what Pleo will do next because he learns. If Caleb and I went to your house to see your Pleo, we couldn’t predict a lot of the things he would do, even though we know everything we put in him. Pleo has the ability to change and figure things out on his own.

Consumers will be able to download and customize Pleo later this year or early next year. We want to give the user the ability to change Pleo’s personality, animations and tricks. We also want to allow developers and hobbyists to take the SDK and motion system and behavior system and choreograph advanced features and animations for new AI functionality.

We didn’t include a camera (or voice recognition) in Pleo because of the price point for the product. Pleo is probably a good hack for a CMU camera, and we want people to develop these sorts of things.

The only way you can create life is to give it choice. Life is very complex, and it has to evolve, otherwise it is a robot. The only way to get complex systems to work is to let them chose for themselves.

by far the predominant

theoretically the most efficient

The '240 is often called "the bicore chip," because we can take advantage of the 240's inverters to turn a single 74*240 into a bicore

The '240 also has tri-state outputs, so an enable line can be used to turn its outputs on and off simply (good for adding reversing capability to a 'bot).

any *cores built with a 74*04 will require additional logic "downstream" to amplify the current to levels sufficient to drive a moto

Schmitt triggers can't easily be used in suspended bicore implementations

use its buffers as little current amplifiers

it is usable for either grounded or suspended bicore designs (but better for suspended)

74HC/HCTxx non-buffers (74HC14 or 74HC04) draw about half of the current consumption, and have about half the drive current compared to HC / HCT buffer chips (74HC240 or 74HC245). Non-buffer chips are thus better for oscillators, say Nv and Nu applications; they are not suited for use in driving motors.

74AC is best suited for motor driver applications with all inputs driven rail to rail.

The '245 is an octal buffer chip, and so has 8 channels of buffering power available for our misuse. This chip was designed for data transmission uses, but we'll misuse it as a motor driver chip

The '244 provides us with 8 (thus the "octal") buffers, enableable in banks of 4. This is a very useful chip for amplifying small currents

it can drive up to 4 motors in 2 directions each, or you can "buddy up" inputs and outputs to drive fewer motors at higher current

it can drive up to 4 motors in 2 directions each, or you can "buddy up" inputs and outputs to drive fewer motors at higher current

If you can't find 1381s locally, you might have better luck finding its European cousin, the TC-54 -- for details on it

Note that if you need more than about 200 mA per motor, you'll need to use an H-bridge, or some similar motor driver

The ideal BEAM circuit would use a low (2V-3V) voltage core and sensors combined with level shifting high (5-6V) volt motor drivers to maximize efficiency.

74ACxxx used in typical BEAM applications uses 4x more supply current than does 74HC/HCTxxx.

These above rules handle all of the commands and expressions of the iLogo language except for the DoUnlessCommand. This command will execute a list of commands unless a boolean condition is met. If so, control is switched to a new list of commands for handling the exception condition.

Each stage of the compiler is designed using the Visitor pattern described in the book Design Pattern by Eric Gamma, et al. This pattern allows tree traversers to be created as seperated objects, instead of doing all traversals as methods of the nodes of the tree

We decided to use the JavaCC/JJTree tools created by Sun for generating a custom parser for our iLogo language written in Java.

The language must have primitives which allow the user of the language to write programs which easily transfer control based upon outside stimuli, in this case sensors on the truck.

An LM18293 push-pull motor driver connects the programmable counter array (PCA) of the 8051 to the truck's motors.

We took the Berkeley Logo language design as our base and then added a primitive for reading sensor and an exception-based control structure.

Set one straightened paper clip aside, you will use it at the end. Bend the two tips of one of the two paper clips as shown.

Put it in through the fuse clip like this, but make sure the notch in the fuse clip is facing out. (The clip has one edge bent inwards. This is the part that has to face outwards). Study this next picture closely.

From the position above, bend the paper clip up and then around the lead of the fuse clip as in the next picture.

Bend the paper clip under the fuse clip...

then up and over the fuse clip:

then around its other lead and you're almost done with the first fuse clip.

First clip -- wire is on the RIGHT side of the fuse clip leads... Second Clip -- wire is on the LEFT side of the fuse clip leads... But remember to make sure the notch in the fuse clip is facing out. (The clip has one edge bent inwards. This is the part that has to face outwards).  Follow all the steps above with the second clip and you get this:

The diodes between the  photo-diodes create a constant voltage drop between the inputs of the inverters. They cause  a dead band to exist between the thresholds of the two inverters. In a way they cause the circuit to act like a kind of window  comparator. Without these diodes both inverters would always be in the same state. With them, there is a small range where their outputs are in opposite states.

The Slave section has only two diodes (or one LED) between the photo-diodes. This makes it respond to smaller differences in light levels than does the Master part of the circuit

Basically, what I did was to stack one SC-H on top of another

I?m using a 74 HC 139 to direct the outputs of the M/S SC-H circuit to the appropriate motor(s)

Cheesy works very well. I?ve had fun making him chase a spot of light from a flashlight around on the floor. He has even been able to detect and react to the flashlight spot on the floor of the brightly lighted lab where I work.

The monocore capacitor is for positive feedback for fast switching between the two motors and to slow down and avoid high frequency oscillations.

R2 together with C2 limits the maximum frequency of the monocore and motor drivers when the light is bright and the sensors are equally lit

R3 together with C2 sets the minimum frequency of the waggle even in the complete dark which is more interesting than twirling endlessly in a circle.

Having said that, maxibug is not perfect: it churns its wheels while feeding and does not back out of the feeding station when full. CD MaxiBug v5 uses just a few more parts but has powerful and efficient motor drivers, its motors are off while feeding, and it backs up when full.

The CD Maxibug v5 uses just one 74AC240 chip

By default at power-up, the circuit is in coast mode. To brake, set IN A to 0 V, IN B to 0 V, and Q5 to 5 V. To spin clockwise, set IN A to 5 V, IN B to 0 V, and Q5 to 5 V. To spin counterclockwise, set IN A to 0 V, IN B to 5 V, and Q5 to 5 V. At any time you can return to coast by applying 0 V to Q5. Or, you can apply pulses of 0 V/5 V/0 V/5 V (and so on) to control the speed. The more time spent at 5 V, the faster the motor will spin. Whenever you change modes, if you set Q5 to 0 V before making changes to IN A and IN B (and then set Q5 back to 5 V or pulsing) there will be no shoot-through.

When light shines on the LDR, it has low resistance and allows current to flow.  When light does not shine on it, the LDR has a very high resistance, and a much smaller current will not flow through it.