Twins bots


Description
Running on PIC16F84 & PIC16F877 Microchip microcontroller. These 2 robots are able to react
interactively with one another via the infra red sensors and sound detector. It can be preselect to
play football -infra red ball , play tag and self interactions. It is similar to Robo Soccer. The
robot with the PIC16F877 has self expression from the LEDs formation.

Specifications
PIC16F84 & PIC16F877
H-bridge amplifier,
IR- sensor and LED,
sound detector,
Contact detector,
2 Motors on Tamiya gearbox
6V+6V power supply.

Problems encountered
Having linearity drive due to limited drive count sensor.
Basically these 2 are practically workable minus the high current drain from the motor.

Wallie robot



Wallie
is an attempt to make a very small and very simple robot which is still able to perform a
certain task. In this case that task is wall-following. As you can see on the picture, Wallie's body
is an old PC mouse. It uses differential steering to navigate across its world. Its two motors are
very small 5 volt gearbox motors. I have salvaged a tape pressing roll from an old cassette deck and
transformed it in a very small castor wheel. This works beatifully.

Wallie uses three infrared obstacle detection sensors to locate and follow a wall. These are mounted
on the front of the bot as can be seen on the picture. One pointing a little bit to the left, one
pointing forward and one pointing a little to the right. These sensors either see or don't see an
obstacle. There is no distance measuring capability available. When an object comes within
approximately 7 cm of the sensor, it will trigger.

The brain of wallie is an ATMEL AT90S2313 microcontroller. It is programmed with the AVR port of the
linux GCC C-compiler.

The wall following procedure is as followes: First, Wallie waits until it gets offered a wall to
follow. In other words: You have to put him so close to the wall that the sensors of the bot see it.
Wallie will then start to drive forwards a little bit in the opposite direction of the wall. When
the distance to the wall gets to great, the sensor pointing to the wall will not see it anymore.
Wallie will then start to drive towards the wall again until he sees it again. Then he starts to
move away from the wall again etc. This way he will follow the wall without touching it. When it
does not find the wall within a short period, this means the wall has moved sharply away from the
bot. Wallie will then start to turn sharpy towards the direction he expects the wall to be until it
is found again. The second special situation is when the sensor facing the wall and the sensor
facing forwards see the wall. This means the wall has made a sharp turn towards the robot. Then
wallie will react by turning away from the wall until only the sensor facing the wall sees the wall.
The third special situation is when all three sensors see the wall. This means Wallie has driven up
a dead end or a very sharp edge in the wall. He will then start to turn on the spot until the sensor
pointing to the front does not see the wall any more. He then faces in the correct direction again.

Seeker Robot


The goal of Seeker is to look around for human beings, drive towards the first it sees and then try
to follow that person. Seeker locates humans by using a Passive Infrared (PIR) sensor. This sensor
is capable of detecting the heat signature of a human being. It is mounted inside the white cone on
the sensor unit at the front of the robot. The white cone holds a freshnell lens to focus the
infrared (heat) radiation on the sensor element. The sensor unit also holds tree SHARP GP2D02
infrared distance measurement units. These sensors take over when Seeker gets close to the person it
wants to follow. This cannot be done with the PIR sensor because it is not accurate and directional
enough at close range. The sensors of Seeker are mounted on a pan/tilt unit. This enables Seeker to
look around and point its sensors at any object of interest in its field of view.

The drive train of Seeker is the same as that of Roamer and Wallie. It consists of two propelled
front wheels and a castor wheel at the back, enabling the bot to navigate the world by using
differential steering.

The brain of seeker is an ATMEL AVR 90S8535 microcontroller. It is programmed in C using the AVR
port of the linux GCC C-compiler.

The procedure to locate and follow humans is as follows: At powerup, Seeker starts to turn on the
spot. When it detects a heat signature, it drives towards it. When the heat signature is lost during
the approach of the target, it starts turning in a circle again to relocate the heat signature. When
Seeker gets close enough to the target, the infrared distance measurement sensors take over. In
order to follow the target, the distance measured by the left sensor is compared to that of the
right sensor (the third sensor is not used right now). If the left sensor measures a greater
distance than the right sensor, it concludes the target is located on its right side. If its the
other way around, it assumes the target is on the left. It will then move its sensor head in the
direction of the target. The motor controller of Seeker is programmed to drive in the direction the
sensor head is looking, and therefore the whole robot will start following the target. If seeker
gets close to the target he will stop. If the person being followed starts to move towards Seeker he
will start to drive backwards to avoid being stepped on. If Seeker loses the target he will start
looking for a new heat signature.

XBot



The robot
was equipped with several sensors while two modified for continuous rotation servos were used to
move it around. The robot's main parts are listed below:

Microcontroller: Atmega 8535 running at 16 MHz

* 4 Infa-Red proximity detectors
(for obstacle detection and avoidance)
* 1 Rotating ultrasonic ranging module
(for measuring distances. +/-90 degrees rotation)
* 2 Wheel encoders
(to accurately measure wheel rotation)
* 1 PIR sensor
(to detect human presence)
* 1 "Line Sensor"
(Line following)
* 1 Radio Data Link
(for telemetry purposes)
* 1 Alphanumeric LCD (20x4)
(mainly for debugging purposes)
*1 Battery level sensor
*3 Push buttons
(to provide a basic user input unit)

Although several navigation routines were implemented the main effort was to enhance the robot with
a self-localization ability (dead-reckoning)

E-card

An e-card is similar to a postcard or greeting card, with the primary difference being that it is created using digital media instead of paper or other traditional materials. E-cards are made available by publishers usually on various Internet sites, where they can be sent to a recipient, usually via e-mail. It also considered more environment friendly compared to traditional paper cards. E-card businesses are considered environmentally friendly because their carbon footprint is generally much lower compared to paper card companies and because paper is not used in the end product.

E-cards are digital "content", which makes them much more versatile than traditional greeting cards. For example unlike traditional greetings, e-cards can be easily sent to many people at once or extensively personalized by the sender. Conceivably they could be saved to any computer or electronic device or even viewed on a television set, however e-card digital content has not yet progressed as far as digital video or digital audio in terms of varied usage.


Full report link: download report

Roverbot



Description



When the robot hits something on the right side of the bumper, the right push button
is depressed. This makes the robot stop, back up, turn to the left, and continue moving forward. If
the robot collides with an object on the left side of the bumper, the left push button is hit. The
robot stops, backs up, turns to the right, and continues going forward. Because of the bumper, the
robot can maneuver around obstacles and keep moving without any human interference.

Line Follower


Functions
The buggy features two main wheels positioned opposite each other, and independently driven by
stepper motors. The chassis is balanced with a simple peg that skids along the ground.
The motors and sensors plug into two circuit boards mounted in the buggy chassis, and this in turn
is linked by means of umbilical ribbon cable, to an input/output port used in conjunction with a
Sinclair ZX81.
The ZX81 provides the intelligence to make the buggy follow a black line (electrical black
insulation tape). It could be argued that a basic line follower does not really require the use of a
computer, with the buggy being made to operate properly by getting the sensors to control the motors
through more direct electronic means. However, using a computer allows easy behaviour refinement by
software changes. For example after the basic line following was implemented the buggy was
programmed to be able to negotiate branches in the line.

Specifications
The chassis is built from a combination of Meccano® and Perspex®. The Meccano enabled a chassis to
be quickly constructed, and the Perspex facilitated the non Meccano parts (stepper motors and
wheels) to be easily incorporated into the design.
The robot electronics comprised two circuit boards - the driver board and the sensor board. These
boards are stacked one over the other.
The step resolution of the stepper motors is 1.8 degrees. To turn this step size into a smaller
wheel travel, a reduction gearing comprising a small cog on the motor shaft and a much larger cog
connected on the wheel is utilised on each motor drive.

Driver board

Two SAA1027 stepper motor drive ICs are employed on the driver board, each one to control a four
phase stepper motor. The ICs simplify control of the stepper motors by requiring just a digital
direction signal (clockwise/anti clockwise) and digital clock signal (advance step) for each motor.
The SAA1027 ICs require a 12v power supply, and 12v control signals. LM324 quad operational
amplifiers are used to level shift the 5v TTL levels from the ZX81 up to the 12v control signals.

Sensor Board
To enable the buggy to follow a black line, two optical sensors (TIL81) are used. They are
positioned at the front underside of the buggy. The sensors are separated by a distance of 1cm.
Additionally an infra-red LED (TLN1 10) is placed between the sensors, so that they are less
effected by the surrounding ambient light. Depending on the surface either black or white the
infrared beam is either absorbed or reflected respectively.

The sensor board comprises two identical circuits each connected to a corresponding optical sensor.
Each circuit converts the optical sensor output from an analogue value to a 5v TTL signal that can
be read by the ZX81 via the input port.

Electronic Billing with full report

Electronic Billing (General) is the electronic delivery and presentation of financial statements, bills, invoices, and related information sent by a company to its customers. Electronic billing is referred to by a variety of terms,including the following:
EBPP — Electronic Bill Presentment & Payment (typically focused on business-to-consumer billing and payment)
EIPP — Electronic Invoice Presentment and Payment (typically focused on business-to-business billing and payment)
"e-billing"
"e-invoicing"
"electronic invoicing"

While there are current efforts to standardize systems for electronic billing and invoicing, there is currently a wide variety of options for businesses and consumers. Most fall into one of two categories:
CSPs (customer service providers) which allow a business to invoice clients electronically
bank aggregators, which allow consumers to pay multiple bills, typically through their bank

Increasing acceptance of e-billing by consumers and the business community (according to Kiplinger magazine, 77% of business owners now favor electronic billing),as well as increased concern for security and the environment, is speeding up the shift to electronic billing from paper billing

report4all@gmail.com

Online E- banking (or Internet banking) project abstract For Computer science B.Tech Students

Online banking (or Internet banking) allows customers to conduct financial transactions on a secure website operated by their retail or virtual bank, credit union or building society.
Features

Online banking solutions have many features and capabilities in common, but traditionally also have some that are application specific.
The common features fall broadly into several categories
Transactional (e.g., performing a financial transaction such as an account to account transfer, paying a bill, wire transfer... and applications... apply for a loan, new account, etc.)
Electronic bill presentment and payment - EBPP
Funds transfer between a customer's own checking and savings accounts, or to another customer's account
Investment purchase or sale
Loan applications and transactions, such as repayments
Non-transactional (e.g., online statements, check links, cobrowsing, chat)
Bank statements
Financial Institution Administration - features allowing the financial institution to manage the online experience of their end users
ASP/Hosting Administration - features allowing the hosting company to administer the solution across financial institutions
Features commonly unique to business banking include
Support of multiple users having varying levels of authority
Transaction approval process
Wire transfer
Features commonly unique to Internet banking include
Personal financial management support, such as importing data into personal accounting software. Some online banking platforms support account aggregation to allow the customers to monitor all of their accounts in one place whether they are with their main bank or with other institutions.

iHabitat - A home automation, security and monitoring system

The iHabitat system consists of several nodes installed/placed around the house. Each node is capable of serveral functions.
The functionality is catageoried into different groups: 1. Communucation functionality gives a node the ability communicate with other nodes or with the outside world (using the internet / phone line / SMS) 2. Sensor functionality enables a node to measure phyisical world parameters like temprature, power consumption etc. 3. Controller functionality enable a node to control equipment around the house. This can including switching on/off appliances, opening/locking a door. 4. UI functionality enable nodes to interface with the user using physical interface and virtual interface. A physical interface could be a LCD display, keypad, LEDs etc. Virtual interfaces include web / mobile based interfaces. 5. Storage functionality enables node to store and log data. Each node atleast one type of communication functioanlity. All nodes are capabable of communication with each other. Gateway nodes are capable of connection to the outside world over the internet, using the phone line or SMS. Bridge nodes are capabable of converting one type of commuication to another (e.g. WiFi to Zigbee). This page is a first draft describing the overall systems and what is expected out of it.  
Objectives: (1) Intelligence: iHabitat shall be able to take decisions on its own based on its learning from its user behaviour. (2) Easy to deploy and use. (3) Open source (4) Strong focus on communication within the network and to the outside world using the Internet.  
User interface: 1. Web based interface (remote administration and monitoring possible) 2. LCD based touch panels around the house (cost too high, only plain LCD displays for now) 3. Regular wall switches for lighting would still work, no need necessary use the interfaces mentioned above 4. Interactive voice based interface (not a priority right now)
Communucation functionality: 1. ADSL for primary Internet connectivity, distributed across the house over WiFi, repeater to extend range. 2. Mobile packet data services (GPRS/EDGE) as backup internet Internet connectivity 3. Sensors and appliance connectivity over Zigbee (also to consider IP over IEEE 802.14.5 wireless PAN) 4. WiFi to Zigbee bridges for easy access to all appliances from the Internet. 5. Security alerts to be communicated over SMS and voice calls to predefined numbers 6. Some nodes of the system to have Infrared to enable the system to control appliances with IR remote controls.  
Sensor functionality: 1.Human presence detection based on PIR, ultrasonic, infrasonicm, visual sensors 2. Sensor network for indoor/outdoor temperature and electricity usage collection  
Security: 1. CCTV type IP based camera survillance system 2. Intruder alarm based on laser trips and PIR for secondary confirmation.
Storage Functionality: 1. Solid state storage (flash memory) for all logs, records. 2. Critical information also to be updated to the Internet.  
Information updates from the internet 1. View RSS feeds on screens across the home 2. User able to set alerts for events (such as incoming mail)  
Power supply: 1 Electrical mains, some nodes to have UPS backup. 2 Small nodes to run on batteries and if possible on solar cells. 3 Battery  
Time synchronization: 1. From NTP servers on the Internet

TeMo - Telerobotics over Mobile packet data services

TeMo is a tele-operated mobile internet robot. While other internet robots mostly use WiFi (or a nearby PC with an internet connection), TeMo connects to the internet using Mobile packed data services (e.g. GPRS / EDGE / UMTS / HSDPA). The advantage is virtually unlimited mobility for the robot.

Simply put, TeMo is a robot that can
Move around and do stuff (since it has tank tracks and a robotic arm)
Can be controlled from any where in the world (since it has Internet connectivity)
Can boldly go where no robot has gone before !! (since it used mobile packet data services for Internet connectivity)

TeMo is controlled using an Ajax based webage. The webpage is served by a tiny webserver running on a mobile phone that is mounted on the robotic platform. TeMo is also capable of sending pictures in realtime to the user terminal (and possibly also video in the near future).

Lets look at TeMo in detail. TeMo is made up of the following parts:
Lego (technic) blocks for the basic mechanical structure.
5 servo motors for mobilty, torso rotation and arm control.
A microcontroller that controls the motors, listens for commands from the webserver
A standard mobile phone that runs a tiny Webserver, connects to the Internet using GPRS/EDGE/UMTS and communicates with the microcontroller over Infrared.

The following diagram shows how the overall system works.