Motor Subsystem;

 After Laying out the circuit diagram and the connections to the various outputs,   we needed small sections of  programming routine so that when  the programmer came to assemble the final developed program,  small sections of code  could be copied and pasted in.

Firstly, we had to devise a code to check that the motor were wired up correctly and that it would turn backwards and forward.

Main:
    low 1        `Drive the motor forward
    high 2
    pause 5000    `Pause for 5 seconds
    high 1    `Drive the motor backwards
    low 2
    pause 5000    `Pause for 5 seconds
goto main        `loop to start

Once this was working, the code was copied and  applied to 2 motors to make sure that they both worked;
 This routine was called "goforward" (obviously)

`To Drive Motor Forwards
High 5    `Left Motor Fowards
Low 4     `Left Motor Forwards
High 6    `Right Motor Forwards
low 7        `Right Motor Forwards

(Note the change in Pins, as this code was run on the fully assembled buggy, whereas the first code was run during  the lab sessions during the first couple of weeks)

Once  we had this  code and sub-system working,  we were able to play around witht the outputs of the chip to create smaller subsections of programming that would enable the buggy to  turn left and right. Here are the devised codes;
turnright:

    `To Turn Right
High 5    `Left Motor Fowards
Low 4     `Left Motor Forwards
`Code To Turn right Motor Backwards
Low 6
High 7
return

 And the code to turn left;

turnleft:
` To Turn Left
High 6    `Right Motor Forwards
low 7        `Right Motor Forwards
`Code to run Left Motor Backwards
Low 5
High 4



These blocks of text where then substituted in to the Alecs program.

Some Initial Programming

A quick bit of programming to see if the buggy was working once constructed:

Sensor Input Program:

main:
READADC 0,B0
READADC 1,B1
READADC 2,B2

Debug

If b0>100 then b3=1


GOTO main:

Motor Test Program:

Main:

High 0 `Run Motor 1(?) Forwards(?)
Low 1
Pause 3000 `Pause for 3000
Low 0

High 2 `Run Motor 2(?) Forwards(?)
Low 3
Pause 3000 `Pause for 3000
Low 2

Goto Main:

Initial Buggy Program Idea:

Main:

Read 0,B0 `Left Sensor written to Bo
Read 1,B1 `Sensor 2 Written to B1
Read 2,B2 `Right. Sensor written to b2

Low 5 Low 4 Low 6 Low 7

Debug `To check working correctly

If B0=1 Then high 5 Low 4

Else If B2=1 Then high 6 low 7

Endif
Goto Main

Evolution Of Buggy

Testing day

Once all of the programming, building and debugging had been completed it was test day. The first thing on test day was to set the robot to the ambient light conditions experienced in the room which meant changing the program slightly to accommodate for this. Redo any last adjustments and then our line follower was off. Having came to Test day we still realised we needed to have a lot more debugging process ,the motors did not produce enough torque, one of the circuits driving the motor board was not working correctly as one of the motors would not go backwards (not a problem for line follower mode but for symbol mode it was).

Our tests went significantly better then the Marked test from the lecturer , our robot managed to sense the line but it did not have enough torque to turn. And on the symbol mode our robot managed to only recognise the Left and Right turn but the action that they performed was not 90 degrees left and right , instead they just continually span round.

Programming

The final programming had been completed. The main areas and problems associated with programming are as follows.

• How to read the inputs effectively, especially as we were reading in ADC inputs and how to convert them again into a binary form , so case statements could be used. We managed to do this through reading each of the inputs into a memory location . Then using If statements these could be analysed and if over a certain value a 1 , 2 ,or 4, which in binary is 001 , 010, 100 could be added to a separate memory location , in my case b3. E.G if my left sensor sensed the line and went past a certain value then in b3 would be 100, if my right 001 and middle 010 or any combination of theses , like if all sensed the line 111. With this case statements could be used. It is important however after selecting the case to erase all the values in b3 so when the programs loops the values do not keep adding up.
• How to change between modes, symbol mode and line follower. As we used a toggle switch which was connected to input pin 7 , we just read in all the pins to a memory location and if over a certain value (because pin7 if on would effectively have a value of 128, and thus make any values being read into the input pins over 128) then it would be in symbol mode and if under the value it would be in line follower mode.
• Lack of program memory, it was soon realised after creating my program that the computer would not allow it to download onto the chip because the program took up to much memory, essentially my programming for the motors which I put into each case was making the file way to big. The way I combated this was to use subroutines. I made one for forward , turn right and turn left. These could be called by using GOSUB...turnright and the program would return to its original location by use of the command RETURN. This saved duplicating lots of code, and made my file size much smaller.

The finished program was as follows;

main:

b7=pins ;read in all pins to memory

readadc 0,b0 ;reading all adc inputs to memory

readadc 1,b1

readadc 2,b2

if b7 <10>

goto symmode ;else go to symbol mode

normal:

if b2>100 then let B3=B3+1 ;right sensor, p

endif

if b1>100 then let B3=B3+2 ; middle sensor

end if

if b0>100 then let B3=B3+4 ; left sensor

endif

select B3 ; case statements for the different scenarios

case %00000000; both motors off and return to select

case %00000001 ; right motor off

gosub turnright

case %00000010 ; both motors on and return to select

gosub forward

case %00000011 ; Right motor off

gosub turnright

case %00000100 ; Left hand motor off

gosub turnleft

case %00000101 ; Error, carry on

case %00000110 ; Left hand motor off

gosub turnleft

case %00000111 ; both motors on and return to select

gosub goforward

end select

debug

let b3=%00000000

goto main

symmode:

if b2>100 then let B3=B3+1 ;right sensor

endif

if b1>100 then let B3=B3+2 ; middle sensor

end if

if b0>100 then let B3=B3+4 ; left sensor

endif

select b3

case %00000000 ; straight

gosub goforward

case %00000001 ; forward 90 right

gosub turnright

pause 1000

case %00000010 ; straight

gosub goforward

case %00000011 ; forward 90 right

gosub turnright

pause 1000

case %00000100 ; forward 90 left

gosub turnleft

pause 1000

case %00000101 ; Forward pause reverse

case %00000110 ; Forward 90 left

gosub turnleft

pause 1000

case %00000111 ; Forward pause reverse

end select

debug

let b3=%00000000

goto main

turnright: ; subroutines for driving motors

`To Turn Right

High 5 `Left Motor Fowards

Low 4 `Left Motor Forwards

low 6 `Turn Right Motor Off

return

turnleft:

` To Turn Left

High 6 `Right Motor Forwards

low 7 `Right Motor Forwards

low 5 `Tur Left Motor off

return

goforward:

`To Drive Motor Forwards

High 5 `Left Motor Fowards

Low 4 `Left Motor Forwards

High 6 `Right Motor Forwards

low 7 `Right Motor Forwards

return

Group feedback and product development.

After the testing of the product resulted in it failing two tests, and only completing the main line following task with a little prod now and again, the group have decided that implementing the following steps would help produce a successful design:

1. Supply a greater voltage to the motors. This could be done by either using the 9V battery, the connection to the motor being controlled by a seperate motor board circuit, or running a further voltage source in parallel with the current supply; maintaining the voltage (4.5V) but increasing the current supply to the motors. This extra step would increase the torque of the motors.
2. Introduce a gearing system to the drive mechanisms. This would allow the buggy to travel at a slower speed, giving the LDR's plenty of time to sense changes in the road conditions and corrective conditions to be implemented appropriately.
3. Change the jockey wheel. The existing jockey wheel would often be mis-aligned when the buggy would try to change its direction of drive; the friction produced fighting against the motors. The installation of two jockey wheels, one in each rear corner, would elimainate this problem and allow the buggy to move more easily.

Development and Progression

The final few days of development have seen a big rise in the level of activity surrounding the buggy. The group have worked hard to develop a well built, professional product that meets all the aims; with numerous problems arising. These problems have seriously hindered progress but have resulted in a better quality product being created.
The problems were:
1. Motor Power. The motors do not have the torque to turn the chassis (which still appears to be relatively light) upon command.
2. Motor driver board problems. Fault diagnosis suggested that the motor driver board was faulty (a blown chip was suspected), but after creating a new resistor board the fault was found to be in the input voltage to the system (the batteries!).
3. LDR sensitivity. As the suspected fault with the motor driver board briefly stopped development of the moving parts, the group focused their attention onto developing the sensing elements. The LDR's and LED's were mounted onto the front of the buggy at a sensible height to allow adjustment; once testing commenced. Upon reflection it was realised taht the variable conditions experienced in the actual testing laboratory (Room 160 in Aston university) were vastly different to a dimly lit basement.
4. Available products/parts. The supplier used to precure all the components and parts had run out of the LED's that were used to provide a more stable light source for the LDR's to detect. This resulted in a change of LED - a solution that quickly enabled testing to get back on track.

Fault Diagnosis

Upon finding the motor circuit was not operating correctly it was decided to trace the fault; so that appropriate action could be taken.
1. Using a continuity tester all the PCB was tested to ensure that no solder had 'tracked' across between lines. Only one case was found and quickly rectified but did not resolve the fault.
2. Using a voltmeter all voltages were inspected. Starting at the main battery pack and traced successfully to the motor circuit board. All voltages entering the motor circuit board were correct but the expected voltages that should have been seen on the motor terminals were not there. This suggests that there is a fault with the motor chip; which willneed replacing.

Final Design

The final and new buggy has been made as a team this weekend. Its chassis built from Durable modelling plastic ,and all the circuit boards soldered up nice and neatly. The jockey wheel has been far improved, and the whole buggy moves in a straight line and does not veer off to one side. The new Sensor array has been made with 4 White LEDS and 3 LDR's placed underneath the vehicle. With testing these appear to work really well giving constant values untill a black line is moved underneath them. However during Testing the motor circuit board has not been working this could either be a fault with the circuit or a blown motor chip.

• 
  

Bugguie Design

The intial and secon Prototype was made using a plastic box with some screws and masking tape. It was decided buy the team that the design of the buggies was need to be enhanced to look more professional. The team decided that we should keep the initial design but the chassis will be built by ourselves and wire the circuit boards up neatly.

For this a diagram of a the layout was required. It was drawn using Solidworks on an A3 sheet with 1:1 scale. This makes it easy to use and construct.

The chaise is a block of wood with carefully placed holes for the wiring. The wires will the run through the holes and under the chassis. This makes the wires unseen from the top and increases the look of the organisation.
As well as the wiring being neatened the team decide that the jokey wheel needs to be strengthened. This could possibly be achieved by changing the material used in construction.

A second prototype has been constructed and a few changes have been made. The chassis design has been altered slightly. A plastic container has been used, which has had holes drilled to allow mounting points for both the motors at the front and the jockey wheel at the rear of the buggy. The buggy appears to be able to move straight, left and right, however it only appears to do this while the jockey wheel is mounted at the back of the vehicle, hence why they are that way round. The new motors are a definent improvement, now that they aren't buckled. Additional improvements that can be made are as follows:

- A more stable jockey wheel.
- A better chassis for the buggy to sit in.

After a lengthy group meeting today, we have decided on a few more changes for the buggy as a whole.

- The inner circuitry will be redone and neatened.
- The inner circuitry will be mounted on a semi-removable board for aesthetics and practicality.
- The jockey wheel is to be reconstructed.

Electronics

The electronic circuit has been built as follows from the circuit diagram (Courtesy of Duncan Scriven), currently it resided on a bread board but will eventually be put on a circuit board to aid in weight reduction.The sensor and provisional LED array have also been made. This includes having 3 LDR's evenly spaced 0 0 0 and an ultra bright LED placed next to them to give light (as mentioned earlier more LEDs can be used. (The LED circuit for now has been made seperate to the motor circuit as to not drain the batteries but it can be attached to a pin.) After Testing the sensor array it became apparant that different ambient lighting affected the sesnor array so my sensor array will need to be completely enclosed so as the only light reaching the LDR will be coming from the LED's. It also became apparant that using just digital inputs was a bad idea having to manually change them when the lighting conditions continually change, so we have changed to reading the ADC output of each of the pins keeping the potentiometers at one level.

First prototype.

The first prototype has been constructed. The group decided to base the design on a three wheeled basis, whereby the chassis was to be made out of plastic containers, to give rigidity and light weight. The use of the original wheels and motors help as we know these can be run effectively without too much complication. Despite this Some major problems have surfaced as a result.

• One of the worm gears is not straight and so will have to be replaced.
• There is a distinct lack of speed and manoeuvrability, however it is still able to run , so placing weight nearer the motors may help , especially when turning.
• As the group decided against lego and other "toys" as this does not show originality, the body had to be made ourselves. This is slightly tedious as nothing will fit tightly , however with the use of drills this situation is being remidied.
• Trying to find an appropriate jockey wheel that can fit with the chassis effectively and to which is effecting the turning. At the moment a lego jockey wheel has been constructed but is ideally not suitable.

Proposed Pin Out diagram

This is the proposed pin-out of the actual PIC circuit board;

Output Pins 0-4 are used to control motor 1 or 2. ( 1 being the left hand motor, 2 being the right hand motor respectively looking at the buggy from the front). The Combinations shown are those to drive the motors forward ( i.e the combination of pin0 being high and pin 1 being low will drive the left hand motor forward, while reversing to Pin0 low and pin1 high will drive the left hand motor backwards.)

The sensor posistions are shown are indicated as if looking at the buggy from the front.

Pin 7 turns on a transistor that activates 5 LEDS mounted above the LDR sensors.

Its pretty flexible so if anyone needs anything moved to make their section a bit easier then give me a shout and ill see if it works and if so ill update the diagram.

Case Statements

The following flowchart code is being considered; utilising case statements to direct the robot:

Let b0 = pins
let b1 = 000111 & pins
select b1
case = 000000; both motors off and return to select
case = 000001; Right hand motor on and return to select
case = 000010; both motors on and return to select
case = 000011; Right hand motor on and return to select
case = 000100; Left hand motor on and return to select
case = 000101; Error
case = 000110; Left hand motor on and return to select
case = 000111; both motors on and return to select


The individual case (ie how to drive both motors will be developed in a later blog).

Programming limitations

As the PICAXE only has 5 inputs , and one input must be used to switch the mode of the LFR from line following to symbol recognition, the amount of sensors we planned must be reduced. We are now reducing the sensors to 3 . This is beacuse when we read pins (all the input pins) these are neatly together at the end of the byte (bit 0, bit 1 , bit2) relating to (pin 0 , 1 ,2) so will be easy to program, and there will only have to be 8 different cases. Pin 6 or 7 will have to be tied down and one used for the switch. The only down side to this is that the buggy wont be able to adjust so precisely as it could with more sensors.

IF/ELSE Case Statements

As part of the development of the programming we investigated using the following If/Else flowchart. Eventually we decided against it as it is better programming etiquette to use Case Statements to achieve the same aim.

Let b0 = pins
Debug Pins; This command would indicate what the device 'thinks' to the observer
let b1 = 000111 & pins
If b1 = % 00000000; No Action
Else b1 = 000001; Hard right turn
Else b1 = 000010; Continue straight
Else b1 = 000011; Gentle right turn
Else b1 = 000100; Hard left turn
Else b1 = 000101; Error.
Else b1 = 000110; gentle left trun
Else b1 = 000111; Continue straight

Autonomous Vehicles

Autonomous Vehicles

This is just a quick look at the uses of smart systems applied to vehicles; the term autonomous here refers to the either the system being programmed to do a set task upon something happening, or being able to “think” what to do; either way it is defined as a smart system being able to perform a task without a “human in the loop” or without being told to.

Obviously vehicles can travel in three main mediums so we will look at theses first;

(to the above left is a picture of "Goliath" a WWII german remote controlled tank; not only was one of the first recored uses of remote control, but also of autonomity in robots. For a refernce, see end of post)

Land Vehicles

The term land here being used to describe any robot that moves over ground. These range from simple vaccum cleaners (see the video elsewhere on this blog) that can clean around a room to quadbikes that can navigate and steer themselves to a set location to deliver equipment as used by military forces and aid agencies and charities.

One of the greatest uses of autonomous robots is in jobs that are deemed to hazardous or risky for a human to perform and as such they have found a niche market as “ bomb disposal bots” or EOD robots.

For completely autonomous vehicles, several considerations are important;

1. Firstly the robot needs to know where it is heading to;

2. Secondly it needs to able to recognise obstacles and then either be able to avoid them or overcome them;

3. For a vehicle to be truly autonomous it needs to be able to figure out where it is in relation to where it needs to get to; In very simple autonomous robots this can be as simple as just set of directions to follow.

4. The vehicle needs to have an idea of how it moves (i.e how long it takes to turn so that it can correct its path)

Air Vehicles

Autonomous air vehicles(excluding satellites which aren’t covered here) are actually the most common type of autonomous robot around, with even toy remote controlled planes having a degree of autonomity in that if instructions cease to be send to it , it will either continue to fly itself or attempt to land in an area that it may know is safe.

Further more just to keep the aircraft in the sky a small amount of autonomity is needed for it to correct itself in mid flight and to keep itself stabilised. While this may not be considered true autnomity it certainly does not require, or even keep a human in the loop to perform these operations.

Due to the relative cheapness of UAVs compared to the manned piloted planes, they are increasingly popular with security ,police and military forces . Robotic helicopters equipped with cameras and infra-red vision are being used by the fire service to try and detect bodies in danger zones : and the same are used by the police to try and track down criminals in the open.

As stated in the considerations above, a UAV must be able to know where it is heading, where it is presently in relation to where it is headed and be able to recognise any obstacles in the way. Furthermore in top of this, it must be able to continually adjust and balance itself to stay in flight.

Sea Vehicles

While they exist and are in use, autonomous sea robots or boats are surprisingly rare, however they are finding use as remote controlled submarines. Indeed most Robotic sea vehicles are underwater submarines and while the use of auton is small as they need to receive human interaction to be told what to look at , there are certain in-built protocols that kick in for the robot to monitor and control itself. ( For example, when running out of power the robot will automatically surface.) Famous examples of uses of autonomous sea robots include the robot that was used to find the ship “Titanic” and the “Bismark”(see picture below)

Due to the lack of knowledge about the underwater world, theses autonomous vehicles require both an internal system to stablise them selves, but the majority of their steering is down via remote control and then guided to where they are needed or/wanted.

Militrary Autonomous Vehicles

As can be seen from the preceding paragraphs, one of the biggest users of autonomous robots is the military and more than any other the US Military, hence a discussion purely on military uses of Autonomous robotics.

Unmanned Aerial Vehicles(UAVS) and Tactical Combat Aerial Vehicles(TCAVs)

Have been in use for many years; in fact the first uses of autonomous vehicles was as aerial spy planes; the premier spy robot in the world, “Global hawk” has now been in the service with the US military since 1998.

Unmanned Ground Vehicles

For every military, body backs are the worst public image they could have; for that reason robotic systems are being used in any situation with a possiblite of danger. “Spy bots” are now used to scout out buildings or potentially dangerous locations; Self steering buggies are now being used as “Pack buggies” to carry equipment and reduce the soliders load. It was only a matter of time before weapons were added to such bots and now weapons placement are not common on military UGVs but for the US certainly all systems sent into an active warzone are equipped with weapon systems. However due to fears raised in popular Sci-fi films and the media ( The films “Stealth” and “Terminator” for example) weapons systems have not been completely autominised for fear of them turning on the controllers or “Accidents”. In fact a US Navy study conducted in 2002 suggests that a autonomous weapons system must always keep a human in the loop for override capability, and that in the future, robotic warriors while probable must be programmed with a “moral compass”.

For where the US Military is heading with UGV technology, watch the video http://www.youtube.com/watch?v=tbtCweucgUg or

Explosive Ordanance Disposal (EOD) Vehicles

Autonomous robotics have really kicked off in the field of bomb disposal: by removing the need the for a human operator to be next to the bomb, they enable dangerous devices to be dismantled or disposed of from a safe distance. As can be seen from the media, the type of warfare being fought in modern conflicts requires large amounts of bomb disposal. Although unconfirmed one model of EOD robot, the “Sword” is said to have disarmed over 20,000 IED devices over its combat career since deployment to Iraq and Afghanistan in 2000.

Unmaned Surface Vehicle (USV)

Despite the interest in autonomous vehicles in other aspects of military operations, the limits of above surface autonomous vehicles have not yet over taken the capabilities of traditional RIBs and manned speedboats . Only one Autonomous vehicles has been confirmed to have entered service with any Navy .

(The protector USV, in service with the Singaporean and Israeli navies, see footage at http://www.youtube.com/watch?v=URyAhMdkWA4.)

Due to its short range, it is simply not practical to have them used for any other duty than harbour patrol.

The Future;

Smart systems are the future, and as they advance more and more they will become more integrated to make tasks both easier and safer making the potential market for autonomous robotics huge.

As stated in speeches by the Minister of state for strategic defence acquisition (Rt.Hon Lord Drayson) “the UK in the lead, globally on autonomous systems. It is a lead which we must fully exploit." Furthermore predicting that the economy for UAV`s let alone autonomous robotics as a whole will rise from £5bn to £40bn within 10 years, smart system design and autonomous robotics is an area emerging that Britain needs to invest in to maintain its lead in the world.

References

BAE Systems “ UK in lead on autonomous systems”

http://www.baesystems.com/AboutUs/draysonautonomous/index.htm

Times Warns “Military Robots must learn warrior code and ethics”

http://technology.timesonline.co.uk/tol/news/tech_and_web/article5741334.ece

US Navy report states “Fears of Robots uprising, suggesting the need for a moral compass”

http://www.engadget.com/2009/02/18/navy-report-warns-of-robot-uprising-suggests-a-strong-moral-com/

Future Weapons; Global Hawk

http://www.youtube.com/watch?v=HR6Cpz-Esyg

Future Weapons Robots

http://www.youtube.com/watch?v=GTabSf1Dxx8

Future Weapons Crusher

http://www.youtube.com/watch?v=tbtCweucgUg

Micro Spy Bots

http://www.youtube.com/watch?v=qZVjtDp0tIY

Goliath Remote Control Tank;

Image taken from http://media.photobucket.com/image/gOLIATH%20tank/abndeuce/767186713_f2e0e184fe.jpg

“Sword” Image taken from

http://www.qinetiq.com/home/newsroom/news_releases_homepage/2007/3rd_quarter/swords_at_dsei.html

Global Hawk Image taken from;

http://www.airforce-technology.com/projects/global/global4.html

Image of Autonomous Robot over the Bismarck

http://www.ethanzuckerman.com/blog/wp-content/2008/02/bismark.jpg

Autonomous Vehicles and Robots

Introduction

Autonomous Vehicles and Robots are machines that interact with its environment. They use various types of sensors to determine the area around them. Based upon the received signal a microcontroller that has been pre-programmed to decides what should happen next. Because of the initial programming complete by humans they need little contact to perform the required jobs that they are designed to undertake.

Example of Autonomous Vehicles and Robots

There are many examples of Autonomous Vehicles. They range from UAV (unmanned aerial vehicle) to UGV (unmanned ground vehicle) and UUV (unmanned underwater vehicle) . All of these are normally used within the military. However they are not restricted to military use.

UAV (unmanned aerial vehicle)

UGV (unmanned ground vehicle)

UUV (unmanned underwater vehicle)

Oil and Gas industry's use UUV to construct detail maps of the seafloor before they start building pipework and rigs. They can also be used to survey pipes once the have been laid. In Particular UUV can allow research to be undertaken in areas that would not initial be possible by humans. Many different sensors can be attached to the UUV. For example they can determine the concentration of various elements or compounds. The absorption or reflection of light and the possibility of microscopic life.

As well as Autonomous Vehicles, robots are available and are used commonly in industry. In industry the robots are designed and used to perform repetitive task. These task would have normally ben complete by humans. By reducing the need from humans to perform the task it has reduced the amount of work a company offers but this in turn reduced the overall cost of the products they sell, however a line of robots will have a couple of operators. This is were the human interaction needs to be. If any errors occur the system can be shut and re-programmed. Even though the robots take over a high amount of labour work they provided jobs to the specialist skilled workers (i.e. the ones who can program the machine). From the industrial point of view robots are invaluable to a company that needs to turn out a high volume of products consistently.

Autonomous Robots are highly used within the car industry. Each robot will have six-axis and be mounted with several tools. A few examples of the jobs that they would undertake are:

• Drilling Holes
• Welding Panels
• Screwing
• Painting
• Cutting

The benefit of using automatic robots are they work to a much higher degree of accuracy then a human can. Not only do they have high accuracy they will complete the jobs at speed reducing the amount of time speed on the convenor belt in construction. They will have an a high initial start-up cost but this can easily be overturn with a quick turn around time with reduced number of rejects. Also if a company wish's to produce a new product they can easily be re-programmed where as a human would need to be retrained with time taken to familiarise them with the process of construction, hence increasing the value of having robots.

Autonomous Robots Working on Cars

Conclusion

Autonomous Vehicles and Robots are extremely cleaver machines that have been pre-programmed by humans to do repetitive or dangerous tasks. They have been invaluable to all types of industries and occupations. Without them a large amount of what we have now would not be available - for example oil rigs that are build more than 500m under water. Using robots has increased the quality of products that can be produced which should to more reliability and confidence in company to produce quality made as well as designed products.

Programming

The following is how i want my programming of the LFR to pan out. The 1's are when my sensor has sensed the line and my O's for when it hasn't. In effect with 5 sensors there are only 32 combinations (binary) that need to be accounted for in my program.

00000- No line stand still.

00001- Hard right

00010-Gentle right

00011-Gentle right

00100-On track keep forward

00101- Error keep on current trajectory

00110-Keep on trajectory

00111-Hard right (corner)

01000-Gentle left

01001-Error

01010-error

01011-error

01100-keep on trajectory

01101-error

01110-hard left (corner)

01111-hard left (corner)

10000-hard left

10001-error

10010-error

10011-error

10100-error

10101-error

10110-error

10111-error

11000-Gentle left

11001-error

11010-error

11011-error

11100-Hard Left.

11101-error

11110-hard left

11111-Stop

I now need to decide weather it is best to use interrupts or not. They would be faster , however, and would allow code to continue uniterrupted untill a corner or deviation from the line would be detected. However my lack of knowledge on programming interrupts in PICAXE Basic will need to be enlarged as it has not been covered in great detail.

Autonomous Robots- Industrial andDomestic

Autonomous robots (Picture courtesy of KUKA Robotics) and vehicles are machines that are capable of interacting with the enviroment through use of sensors and programming. In effect they are "Intelligent" in the way they need little human contact, to carry put they're desired tasks.

The different sensors can sense many different things, some ,like humans, sense heat, light,sound, touch but as sensors are so varied , robots can sense atititude , latitude and longitude, UV, Infra red and react accordingly with what they find. Some intelligent robots , using cameras can sense depth of vision and objects that may come in its path. In industry Autonomous robots can be used in factories for producing goods, the classical use for industrial robots was to just work on a cordinate system, e.g. Place screw A at 10cm Screw B at 5 cm, but new developments mean that robots can sense the object they are working on. This can allow for less errors and smarter robotics that can adapt if the object it it working on is not entirely perfect, or it can handle different objects at different times without having to be reprogrammed completely. This ultimately reduces cost. One example is for using robots to pick up parts from conveyor systems, which can be an expensive task with "unintelligent robots" by use of "2-D vision" cameras can locate different parts and are able to control an arm to pick up said parts.

As ever ,after industry , domestic autonomous robots have come into use. Irobot has been developed to deal with domestic vacuuming. Its sensors detect when objects are in its way, what floor conditions it is travelling onto, and it can even detect its base station , so can recharge itself when its batteries are low. The way in which it can negotiate obstacles is interesting, in this case it is randomness , the cleaner robot will try many different approaches until it finds one which can work "randomness", whilst some more expensive military robots can create a map of the future surroundings by use of its sensors , building up a picture through which it can navigate easily through. The Vacuum cleaning robot can even find its base station to automatically charge from, with the base station emitting an infra red signal with which the robot can follow, which is a way of "foraging" just like humans do for resources. (Video courtesy of Irobot corporation)

Group Research - Human Factors and concerns with UAV's.

The following link from S. McCarley & C.D. Wickens(1), et al,highlights the main issues identified in this area. To summarise they are:
1. Displays and Controls.
2. Automation and System Failures.
3. Crew Composition, Selection and Training.

To add an interesting addition to the automation category however, at what level of automation should a human decision be compulsory. Is it okay for an UAV to decide to destroy a high profile military target at cost to civilian life/infrastructure?


(1) McCarley S.J. & Wickens C.D. (2005)
HUMAN FACTORS CONCERNS IN UAV FLIGHT
Institute of Aviation, Aviation Human Factors Division
University of Illinois at Urbana-Champaign

Tracked Robot Research:

The idea of having a tracked line following robot has been floating around in our group for a bit now and so here is a bit of research in order for us to make a better decision for our final design.

Pros of having a tracked robot:

1. It will make our robot look really cool.

2. It will be fairly easy to implement.

3. Each track will be individually driven, allowing on the spot turning.

4. The tracks act as a break allowing greater accuracy of movement (turning).

Cons of having a tracked robot:

1. The robot will have to have special wheels in order for the tracks to stay on in motion especially when turning.

2. Could add cost to the project.

3. Might need a slightly greater power through the motors in order to achieve the same performance that a non-tracked robot might achieve.

All in all, I think giving our robot tracks will give it a slight edge over the other robots and I think it will be easy to do. Looking for ways of providing the tracks, Lego Technic looks the better bet over simpler ideas such as elastic bands due to the fact that it will address the 1st con. As for the other cons, 2, I think will be a pretty small cost and 3, I think we wont even notice a drop in performance at this level.

My final view would be to implement the track idea on the robot and if it goes horribly wrong, then change to the 3 wheeled option.

Here is a nice web page on how to construct a tracked robot:

http://roboticsforyou.blogspot.com/2007/01/tracked-robot-fabrication-techniques.html

Below are some images of track possibilities:

Programming and Limitations

Before we start programming we need to know the limitations of the PICAXE board.It can only store 14 variables and has only 5 inputs(of which only 3 are ADC) and 8 outputs that can transfer useful data. We also need to know the amount of sensors and the configuration these sensors are in . Through looking at research, 2 sensor layouts are domianant, an inline configuartion or a upside down V configuration.

O O O O O -Inline

O

O O

O O - Upside down V

The advantages of an upside down V become apparent if ,on a course ,there is more than a 90 Degree turn. (Which on the course this robot is going on there wont be). However I believe that in-line sensors are good enough , and make it much more simple to program. Having researched how the line follower will work I prepared these diagrams, that will explain further the movement of the robot whilst following a line and the the sensor configuration and how it will work.

Practically using sensors i can determine position on the line and can start preparing Programming flow diagrams, however these will be quick to change in the debugging process once the rest of the robot is built.

Initial Testing - Motor Torque

Initial Testing - Motor Torque

Today Initial testing was undertaken on the motors provided. This was to identify if the motors that have been supplied are of high enough torque to potential move the buggy along.

This was carried out buy a simple test of mounting the motors and attaching some wheels. To simulate the weight of the batteries/ circuit board etc. The mains power supply was used. See images and video bellow.

Test Rig

Close Up

Wheel Spinning

As can been seen in the video the initial test was successful, however some issues did arise.

It became apparent that the wheels that have been supplied do not have enough friction to handle the power of the motors (see video below). To overcome this issues we simply placed some duck tape onto the wheels to gain more traction. As a result the test rig moved much better(see video below).

Wheels with Duck Tape

Initial Buggy Design

Further developments to undertake from test rig.

See if the design will be stable under loading

See if the design will work with the designated sensor

Increase the friction of the wheels

Circuit board/motor/battery layout.

Progress report - 15/3/10 - Ian Thomas

The following issues were discussed in the classroom session (15/3/10):

Type of Design -
4 Wheels. Harder to setup - Unnecessarily so.
2 Wheels. Unless perfectly balanced it would be likely to drag - this was seen as an unprofessional approach.
3 Wheels. Manouevrable and reasonably easy to construct, if not the most original design.
Tracked. Good manouevrability but complicated to construct and needs specific parts.
Hover craft. Too complicated with a lack of manouevrability.

The group decided to analyse a 3 wheeled design and a tracked design further.
TRACKED - Luke Hildred to investigate available track parts.
3 WHEELED - Excellent control. Favourite of the group.

Sensor Choice -
MAGNETIC - Reed switches (Requires further investigation and testing). The less sensitive switch provided in class isn't up to the task - Duncan Scriven to investigate other options.
INFRA RED - Cheap and effective in the right conditions. Lots of online reviews have recommended that these aren't used so the group have decided to forget using them).
LDR - Cheap and effective with extensive research readily available.

Research-Sensors

One of the biggest decisions in the project is what sensors to use.Initial research on sensor types suggests there are 3 primary sensor types we can use , which include reed switches , LDR's and IR sensors. The following pictures show the pros and cons of each sensor type.

Chassis/Casing Design Ideas:

Looking on the internet at similar projects, I have seen that the chassis/casing is only dependent on a few things;

1. Size of the internal circuit.

2. Any Sensors that might interfere with the casing.

3. Method of propulsion.

Due to these factors being limited in number, you can make the chassis/case as simple or as complicated as you want it to be. Here are a few pictures of examples:

As you can see here a number of different method for constructing the Chassis, a few more ideas are listed below:

1. Lego.

2. Meccano.

3. Airfix.

Luke Hildred

Gantt Chart, Ian Thomas

I have created a Gantt Chart to track the progress of the group and make the allocation of tasks easier. It cannot be uploaded to this blog; so it will be utilised at the classroom session each week. All group members will receive an up to date copy each Tuesday; where new tasks will be agreed and documented.