After a hard days debugging....

It works!!. Albeit crudely. It now maps an area until it becomes enclosed in already mapped areas.
Here is a vid of it working.





and here is the screen at the end

I can now move onto a search algorithm.

Back in business

Hard work has paid off and I have managed to complete a batch of assignments to open up a window to get more work done on this project.
Yesterday I fired up K9 from his long hibernation on top of my wardrobe and prepared a sizeable area for him to map.
I discovered a hardware fault with the drive system where the right side is underpowered and appears to be a loose connection somewhere on the motor drive circuit board. Just poking around to find the fault seems to have cured it for now so I am going to leave it as it is as investigating in detail is going to take up valuable time.

I have now got K9 mapping an area with some assistance. Turning is not an exact science in this case and the robot needs correcting sometimes. This could be rectified by throwing more money at it and incorporating a digital compass or some more accurate wheel encoders but I do not have time nor money for these.

As expected the robot maps and leeps turning with a preference for left until it spirals in on itself at which point the software gets stuck into a loop and has to be terminated with task manager. At this point this is exactly what I wanted it to do. There is a small bug where the motor values are getting erased on multiple turns but I am hoping to find that one today.

I have also Implemented the bump switches and pause feature so that the robot doesnt try to climb the furniture and walls and also the pause button allows manual course corrections to be made.

I will upload some video of the mapping in action when I get a minute.

Next step is to implement a search algorithm so that when the robot spirals in and stops it will then search its database for a nearby square to go to and start mappping again.

Just a quick note

Project is on hold whilst other higher priorities are dealt with.
Project will probably not now meet completion but I will try and cover as many aspects as possible.

PID completed so far

I have spent all day on the PID aspect and trying to tune it correctly.
I have had to alter the algorith slightly. I kept getting overshoot to the left when tuning the pTerm part so I inverted this particular term on the output which seems to have cured it. I also divided the output by 2 as I was adding the value to one motor and subtracting from the other and in effect multiplying the output so dividing seemed to stop the frantic oscillations which were occuring as soon as the PID made any small adjustments.
The other problem was that the PID was simply not getting enough data. The encoder wheel in the chassis is quite slow and had one hole in it so I decided to take the chassis to pieces once again and drill extra holes in the cog so now each has 4 holes giving 4 pulses per rotation meaning errors are detected earlier before the robot veers off course and starts to oscillate due to insufficient data.
With the software and hardware problems sorted out it was quite a simple task to tune the PID to make k9 go in a reasonably straight line. According to the hardware the robot is going straight but in reality it is skewing slightly sideways but I am pretty sure this is down to the weave of my carpet.
I found the maximum number of samples I can reliably make is 4 per second. I am hoping object scanning will not drag this down otherwise the PID will need tuning all over again.
Next step is getting the scanning side working but I have a horrible feeling i may have put the sensors in the wrong place.

PID Controller

I have been working on the PID controller element of the software as I now have an object oriented program layed out.
To test various elements of the PID controller I have had to first use a disk dump to dump all of the figures produced to file for examination then as I narrowed down the PID settings I used the InputBox method so i could enter figures manually without having to recompile the program every time.
At the moment I am only using Proportional control with a gain of 2 which gives me an almost straight line and any other setting result in massive overshoot. The robot is only sampling PID 3 times per second so I may need to optimize the code a little further. Also the wheels do not seem to send enough data so I might have to drill a few extra holes to get more pulses per rotation.

Software is taking a new direction

After writing the software for a while now it has become more and more complex so I have taken the decision to break it down into chunks.
The best way I could see to do this was to use the object oriented approach.

I have gone through the grammatical analysis process of Object Oriented Analysis and implemented the classes in VB.

The robot itself is now a class of its own along with the main form and PID controller.

Today I took the PID code from 'PID without a PhD' which is written in C and re-coded it in VB whilst adding some new bits and pieces to calculate the position and error.

This project is becoming an all-consuming monster and is taking up the majority of my time.
I hope I can still meet my final goal while still concentrating on all the other work I currently have on other parts of the course.

Software requires a re-design

I have been writing a fair bit of skeleton code to get an idea of where i need to go. I got a DLL from Velleman which emulates the card by sending the inputs to the outputs. This will be very useful for testing without having to upload to the robot every time. THis is handy at the moment as I blew up the power supply by accidentally connecting the battery to the PSU instead of the robot. This is because the connectors are exactly the same so I need to mark them up to avoid this happening again.
To test the DLL I put this together

Private Sub frmMapping_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim intInput As Integer

        OpenDevice(0)
        intInput = ReadAllDigital
        PrintText("Input " & CStr(intInput))
        SetDigitalChannel(1)
        intInput = ReadAllDigital
        PrintText("Input " & CStr(intInput))
        intInput = ReadAnalogChannel(1)
        PrintText("Input " & CStr(intInput))
        OutputAnalogChannel(1, 234)
        intInput = ReadAnalogChannel(1)
        PrintText("Input " & CStr(intInput))

        CloseDevice()
    End Sub

There is a subroutine called PrintText to add the text to a log file.
I now need to go back to the design of the software and redraw a more detailed flowchart. This is inline with my build-and-fix design methodology.
My reasons for this are that while writing the skeleton code it has become apparent that my plan to write mapping software then location software will have to be merged as the main search algorithm is required in the mapping stage to locate and move to unmapped areas.

PHASE II - Software

Over the last 48 hours I have begun programming the main software. The manual control software was written to test the robot and remains in beta stage with some tweaks required to make it work properly.

 The main focus now has been the mapping software. It was my original intention to split the software into mapping and location. It has become quickly apparent that both will be done at the same time as the mapping side requires route searching to find unmapped areas.
Instead of using an array to store data I have taken what I learnt in server-side programming and decided to use MySQL. On the server side of the software I decided to go with easyphp as this installs MySQL and Apache with everything needed to make the two work together and provide the MySQL web interface. This will make database maintenance much easier and save lots of time when compared to a command line interface. My code so far has consisted of opening the database and making sure the table is populated. I have also drawn a grid on the screen to represent the robots surroundings. To connect to a SQL database I had to download the MySQL .NET connector to allow VB to talk to the SQL database.
If the program has to generate the database I added a dialog box with progress bar as it can take some time to complete.

After talking to Velleman via their forums I have also got a DLL for the k8055 USB board which emulates the connection to the board meaning I can do some testing without having to upload to the robot.

It Broke!!

I took K-9 out for a long test drive and the drive system failed. This meant having to take K-9 to pieces where i found the gearboxes were not assembled particularly well so once these had been stripped and reassembled the drive system appears to be working again but has slowed on the right side. This may need replacing at a future date but I will see if the PID software can overcome this.
While K-9 was having open heart surgery I decided to take the opportunity to fit a webcam into the head. I had bought a micro-cam some time ago and picked a low resolution camera to save on processing time and network bandwidth. To fit the camera I removed the original casing and drilled a hole into the head of K-9 to take the lens. The power LED I had fitted needed to be removed to accomodate the camera PCB and the camera was superglued into place.

 

I then added a new power led which would fit into the small gap left above the PCB. This came in the form of a blue 3mm LED.

Good old superglue is used here again to fix the LED in place.

Here is the front of the head.

 

Without bright light the camera is hardly visible. 

Another item which needed attention and came to light during extended testing was a build up of heat inside the robot. The heat sinks on the H-Bridge get very warm during operation and are uncomfortable to the touch. The H-Bridge itself will operate comfortably up to 125 degrees Celsius but the other components will not so this heat needed to be removed. I decided to fit 2 slim 40mm fans to the front of the robot to pull air through the body.

Here is a picture of the marking out before drilling with a hole saw.

The fans are simply connected to the 12V output of the PC power supply.
Here is the final result of the newly re-assembled K-9.

A lot has happened - The hardware is built!!!

There has been a lack of blog post recently due to exam season but I have been busy during this period and frantically getting the hardware built.
Using the vero-board designs I mapped out the track cuts onto the board with marker pen and cut them with a drill.

 

Once the tracks were cut the next phase wold be to place the links and components on the top side of the board. This was done by marking the board with marker pen again and following the diagrams.

Once the board was built it needed to be checked with a continuity meter for shortsand then wired up and tested.

 

The same procedure was repeated for the output board too and the completed boards stacked with an insulation layer between them. After the breadboard test I decided to add heat sinks to the main output darlingtons. During the test of the boards it was noticed that the circuit was unresponsive and with a 12V input the motor outputs were only outputting 6.8V. I rectified this by changing the 1k resistors for 220R resistors on the opto isolators. Here is the completed stacked boards.

Note the fuseholder added. I did this as a safety feature and to avoid damage to the circuit boards in the event of a fault. The LiPo batteries are capable of a discharge current of 100A so should be treated with a bit of respect.

In this next picture you can see the modifications made to one of the Velleman boards. The staples pushed into the IC socket bypass the socket where the darlinton driver chip was which is not required in this case. Also you can see the two leftmost resistors have been removed. There is a modification on the underside of the board where the pwm output from the PIC have been connected directly to the pwm outputs on the board and the tracks cut from the other drive electronics.

My chosen method of attaching the boards to the body was cable ties. Cable ties allow for a little adjustment once fitted and look reasonably tidy. 

The next piece of hardware to fit was the optical sensors to measure wheel rotation. These are Optex OPB360T slotted opto-switches. Fitting the devices came down to a combination of old Meccano, computer screws and superglue. The old Meccano is some cheap generic stuff my kids had which had got a bit bent along with some spare parts. Lucky for me the generic stuff is very easy to bend and reshape. The opto-switches need a resistor inline with the transmitting LED to stop it frying and i then took the leads from the opto-transistor side and fed them directly into the Velleman card. I was hoping that the short circuit generated by the transistor would be enough to trigger the inputs on the card. The card itself has +5v fed through a 10k resistor meaning the transistor would have to sink around 0.5mA which is well within the spec.
My initial tests showed that the IR shone straight through the translucent gear wheel making it useless. First thing i did to fix this was to turn down the brightness of the LED by using a bigger resistor so I replaced the 220 ohm for a 1k to pull the current right down. The forward voltage of the LED is 1.7V so this would give me an overall current of 3.3mA.
This was still not enough so I decided to make the gear wheel with the hole in it opaque. I dissasembled the gearboxes and removed the wheel in question then printed out 2 black circles of the correct size. I cut these out and glued them on to the wheels (i had previously tried just colouring them in with marker pen but this didn't work). After the glue had dried i poked out the holes in the gear wheels and reassembled the gearboxes. This worked brilliantly.

Here are the pictures of the chassis.

Here are the bare sensors attched to the chassis using the Meccano brackets which are superglued to the chassis.

And here is the final result.

 

 Now it was time to attach the chassis to the base of the robot, add some connectors and wire in the sensors.

This picture shows the attached parts. The top of the picture shows the circuit boards strapped in with a sheet of antistatic foam wedged between them to prevent pins touching each other. In the design I neglected to leave room on the boards for PCB posts!!

 

Note also that I have removed the USB connectors from the Velleman boards and soldered the cables in directly. There was not enough room for the very large USB plugs to fit either horizontally or vertically. the velleman boards are held in by a cable tie and the rubber feet on the bottom of the boards.

The next stage was to add the sensors to "see" the outside world.

First I installed the sharp GP2D12 sensors. The front one was fixed by drilling two small holes into the front and attaching with screws. I did not want the side sensors to stick out of the robot so attached them to the drive chassis. Not wanting to penetrate the motors or gearboxes i used superglue to attach these.

I also added bump sensors in the form of long-lever microswitches. The second-hand Meccano came in very useful here once again. They were wired with a common ground connection. The 2 front switches were wired in parallel. Here is the end result.

 

"How do you get those nice twisted cables?" - The answer - Cut the individual wires to the same length. Shove the ends into your cordless drill and tighten the chuck on them. Hold the other end firmly and pull the trigger. Voila! - Neatly twisted cables!!

I found the GP2D12's to give rather erratic results and examination of the data sheet says to add a 10uF capacitor to the supply of them.

Thats the 10uF right in the middle of the picture screwed into the connector block.

Here is the robot prior to assembly.

 

Note the wires and connector block coming from the head. These would be wired to a relay and then on to the velleman board. As you can imagine it is a bit of a tight squeeze inside the body of K-9.

The head would be the final thing to get going before closing the lid.

(Sorry the video is rotated)
This is K-9 without his head just to test all the electronics are working (as you can see the kids like it too).

Here is the testing of the nose and ears after wiring up on a test rig.

And here is the finished article

This is K-9 attached to the charger.

I am very happy with the way things have gone so far - Now its time for programming.