Group items tagged

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.

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

Photovore, Split Brain Approach This algorithm works without comparison of photoresistor values. Instead, just command the right motor based on light from the right sensor, and the left motor with only data from the left sensor. You can also get interesting variations by reversing the sensors for a cross-brain algorithm. pseudocode: read left_photoresistor read right_photoresistor move left_wheel_speed = left_photoresistor * arbitrary_constant move right_wheel_speed = right_photoresistor * arbitrary_constant loop

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

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.

John-Isaac Mumford started off by simplifying the Maxibug design, and wound up with an entirely new circuit -- Mazibug

The tactiles switches behave even more strongly: if a switch is closed then the bot turns away unconditionally. If both switches are closed the robots reverse straight back regardless of light level.

When the robot bumps into something on one side, it over-rides all the photodiode circuits and reverses the motor on the OPPOSITE side

From the title it would appear that all 4 photodiodes face forward but the 2 inner PDs face directly forward and the outer 2 are angled to the left and right

The Basic Stamp > interprets instructions in real-time, essentially running a virtual machine on the PIC. This means that it is much slower

The Stamp implements a complete solution on a single PCB. In comparison, a bare PIC requires a separate power regulator and substantial decoupling on its output.

When ALI bumps into something it will go backward for a short time and then go forward in another direction, so they will find their way all alone.

The first one is a light seeker and the second one is a line follower. This version I like very much.

When you are making the line follower you need to place the small light bulb. The light seeker doesn't need it.

When bumbing into something it can also reverse for several seconds. The time of going reverse can be changed. I've used 2M2 and 3,3 uF, this will give a reverse time of about 5 seconds

For the LED’s you can almost use any type or color, I used red ones 5 mm.

When you "power on" Bully it will first go backwards for some time. After a few seconds it seems that it doesn’t know what to do, it looks like it’s shivering. Then it starts of going to the brightest lightspot it can see, first slowly and then like "in a hurry". When it reaches the lightspot it makes turns which make it look like it’s happy! In the time doing all this stuff, each bump into a obstacle makes it move backwards for a few seconds. The time doing this can be changed with the 10 uF elco. Smaller means less seconds and bigger means reversing for more seconds.

by far the predominant

theoretically the most efficient

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.

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.