Robot Car V1.0

A few months ago we created a cardboard framed "robot" that moved forward when three sensors on the front were covered. The wheels were made out of milk tops and chiseled wood. The batteries were so heavy we had to hold them behind the car as it drove.

It wasn't fit for purpose but was a great proof of concept. We decided to start creating the robot for real. I'm going to document in parts the progress we are making.

Initial Design

On the back of a "beer mat" we sketched our rough idea.

Parts To Buy

-------------------------

4 Arduino Smart Car Robot Plastic Tire Wheel with DC 3-6v Gear Motor - £5 to £8

Aluminium offcuts - £0 (up to £14)

Arduino Uno r3 - £2.40 to £8

2 9v Rechargable Batteries - £12 - £30

4 channel 5v relay module board - £1.83 to £6

6+ Photo resistors - £1.50 to £3

Various Jumper Wires - £2 to £4

----------------------

Total Cost: £24.73 to £73

----------------------

  Our first task was to create a prototype so we knew how to cut the offset of metal we had. The idea based on the above diagram was to have a flat piece of aluminium with a slight protrusion either end. The plan is for bi-directorional movement of the robot so it will eventually move in both directions with no clear "front".

Cardboard Prototype With Part Placement

  The prototype measured at 19cm x 9cm with the tops coming in by 1cm either side. We also measured some brackets that could be used to hold the motors and therefore the wheels in place.       

  These were 11.5cm in length. We then cut these out of the aluminium offcuts we had.

********************

Lesson 1: Don't do this in a shed on an allotment with no lights at 8pm in October

      ********************

********************

Lesson 2: If you need 4 equal length pieces... measure them correctly

      ********************

Having cut two of the metal pieces a little short we decided to make a smaller two wheeled car as it was too dark to cut more aluminium strips.

  The next step was to bend the metal strips that would hold the motors and to solder wire to the motors using red for positive charge and black for ground.

  Once the wheels were in place we secured them by drilling a hole where there was a small plastic dial on the gears plastic. This allowed the gear to sit comfortably. After riveting the holder together the gear was solidly in place and each of the two sides were connected to a long metal strip which connected them.

  At the centre of this we sellotaped one of the 9v batteries and connected wires from each of the two motors to the batteries positive and negative.

  Having both the positive wires from the motor go to the negative on the battery and vice-versa meant the affect was for the robot to spin around in a circle. However having the two motors positive and negative wired to opposing positions on the battery will have made it go straight.

  Just for good luck we added a tail to one of the sides. This stopped the motors wires from dragging on the floor. The video below shows it in action.

-----------------------------------------------

In Action:

Genius Advanced Mega Pixel Camera - Revealed

  Whilst travelling and teaching in Chile, my friend Ben and I had lost our camera whilst in Santiago, so went the next day to Maipu to buy a new camera. We were on a money saving mission and I paid somewhere in the region of $10,000 - $20,000 (CLP). Which is about £12 - £22 on a Genius Advanced digital lens upto 12mega pixel camera. The camera was great for the time but soon fell out of my graces when we landed on home soil and it's low mega pixel and short battery life were outweighed by the quality and ease of just having an iPhone.

Having now been sat in a cupboard for the better half of three years it was decided that it'd be much better if taken apart to uncover the secrets within. Here is the journey.

Thus far, thus easy. The above photos show the front "shell" with all the information attached clipped to the camera. At the back two solitary wires connect to the "capture" button which allows us to take photos.

In the third photo you can see where the SD card inserts. Just in front of that (closer to the front of the photo) is where the lithium battery sits. The battery itself is 3.7v / 550mAh which I can use in the future if i can find a safe way to charge it.

A small weight has been added to make the camera seem more 'authentic'

Now, when the camera was whole, there was a small toggle you could press on the right hand side with a picture of hills and then one of a flower. It would appear these were to give a landscape and portrait effect to the images being taken, although in truth there was a very marginal difference between the images. left - portrait right - landscape

I'd originally thought this would be a digital alteration but was actually achieved mechanically using a push lever up or down. The affect of pushing the lever is changing the focus of the lens, though to two specific places so not very useful. 

 

The lever that changes the focus of the lens

At the back we can start to see the motherboard with its in-built controls that attach to the monitor. The monitor itself is a "2.7 inch 39 pin TXDT270CDR-8 LCD SCREEN Digital camera monitor" which hopefully can be used in later projects. The monitor simply unplugged from the motherboard and can easily be used again. Also to be seen is a small capacitor which we believe is used to store energy which eventually allows the "flash" which would make sense as I could never flash when on the last two bars of battery.

There was lots of salvageable parts including the little screws which will come in useful in the future.

One of the parts I was most fascinated with was the lens, which was just two moveable bits of metal attached to the glass to change the focus.

I couldn't get the glass itself out but overall it was fun to disassemble, though not designed to be taken apart so impossible to put back together again.

I'm looking forward to playing about with the monitor in the future - if anyone has instructions for these or know where I can find some it would be hugely appreciated.

All the bits in a single photo.

Creating a custom add on for IBM Pure Application (PureApp)

I wanted to define the uid and gid for the mqm user and mqm group in a pure application pattern. On deploy, if the mqm user doesn’t already exist the IBM MQ Advanced component will create the user for you with a set uid and gid.

In PureApp you can deploy scripts but these are only initiated after the components have been primarily installed which automatically sets the uid and gid. To set your own uid and gid you need to modify the user and groups id’s after the component is installed with the following commands in a script;

if [[ ${user} == "mqm" ]]; then

   echo "making directory /var/mqm owned by mqm"

   chown -R mqm:mqm /var/mqm ;

   find /var/mqm -gid 1414 -exec chgrp mqm {} \;

   find /opt/mqm -gid 1414 -exec chgrp mqm {} \;

fi

However, this would not be considered good practise. Instead you should use an add on which is implemented on initiation of the operating system node. There is an included add on called “default add user”

As you can see from the picture this allows you to define a user and a password. The problem is that the uid and the gid are set randomly by the operating system and for the user mqm the home directory would be /home/mqm but should be /var/mqm for the installation of MQ.

Instead I decided to make a custom add on by going to “catalog -> Add-ons” in pure and finding the current “Default add on” and downloading it from the parameter “add on package file”. This unpackaged zip has three files; an executable file which holds the commands to create the user, the cbscript json file which holds the properties that can be seen on the PureApp interface and a file called extended attributes which just has some extended attributes, you do not need to touch this file.

I altered the file names in the cbscript.json so that the PureApp system sees the new add on as a different add on and doesn’t try to rewrite the old, the important part here is to change "name": and/or "version":. See the image below for an example.

I then added parameters for the user to input; mqm_uid, mqm_gid, mqm_userhome, mqm_group and altered username to mqm_username. These parameter names must not collide with environmental pre-existing parameters, for example the parameter “uid” would cause a failure because the parameter “uid” is already on the operating system environment.

Then I edited the adduser executable file (and renamed it addmqmuser) so that it created a user based on the parameters given.
 

After saving the changes that had been made, I compressed the three files into a singular zip and called it addmqmuser.zip which can then be imported directly into the pure app system. Go to “catalog -> Add-ons” and select “create new” which asks for a zip file. Select import and voila the add on is ready to be used. You should be able to see it and use it on your pattern.

                                     
You can see if this has deployed on “pattern -> virtual system instances” finding the correct deploy and using the “+” next to the node name in the virtual machine perspective. It will be included in the “script packages” section and can be verified with a green tick.

CAUTION: These custom add ons should be made with care and are difficult to troubleshoot when they fail. You will want to test them on a “safe” environment (non-impact) before using them anywhere live.

By following these simple instructions you can now create an add on of your own which can set users and groups on the pattern interface with the parameters you need.