Gadget design, robotics, hacks, DIY technology and more.

Update:

Read the follow up posts: Panoramaker, where I expose the software, and Automatic Panoramas in Montreal, where the final result can be seen.

I have finally completed my second project sponsored by RobotShop. I apologize for the immense delay, I really missed my promise of rolling out a new project every two weeks. Let’s just say that I had a lot going on lately and I could barely keep up with my obligations, let alone blogging or building new projects.

Place Ville-Marie Panorama

This time, I built a panoramic camera. My main objective was to have a platform that can be used with pretty much any camera and that can produce panoramas with a minimum of work. If there is enough interest from the public and if this prototype is well received by the DIY community, I’m planning to produce (and hopefully sell) kits that would include all the parts to build this device.

Materials

• Hitec HS-785HB Winch Servo Motor
• ServoCity SPT200 Direct Drive Pan & Tilt System
• Pololu Micro Serial 8 Servo Controller
• Hitec HS-425BB Servo Motor
• A digital camera
• Small plastic container
• Battery holders
• (Rechargeable) Batteries
• A piece of aluminum (I used an old heat sink)
• A long nut (of the same size as a tripod screw)
• A screw (that fits into the tripod attachment on the camera)
• A tripod
• Cable ties
• A small piece of neoprene (or any other mushy substance)
• A USB to Serial cable
• Some female headers and wires

Putting It Together

Panoramic Camera Mount

The first step was to put together the ServoCity Pan and Tilt system. This took away much of the building work since it is really simple to put together in no time at all. Nevertheless, I applied some modifications to it: I discarded the bottom plate that should be attached to the panning servo (since I am using a larger winch servo that would not fit otherwise), and I drilled a hole on the top plate in order to be able to fasten the camera to the rig. Note that I also included a little piece of neoprene that was lying around in order to prevent the bottom of my camera from getting scratched.

The mounting hole for the camera must be placed so that the lens’ pupil is at the centre of rotation. This way, the horizontal rotation axis will be close to the no-parallax-error point  (or whatever it is called) of the camera and will minimize the parallax errors.

Then, I used an old heat sink as the main structure since it is sturdy and basically free. I used the trusty Dremel to adapt it and cut the proper holes and slots in order to mount all the remaining pieces. The pieces to be mounted on the aluminum plate are the battery holders, the Pololu servo controller, and the winch servo motor. (or whatever it is called

I encapsulated the Pololu servo controller in a small plastic container I got from for free while on a trip with my girlfriend to the beauty/ soap/cream shop. I also used two 2-AA battery holders in order to provide power for the servo motors. I used 29000 mAh NiMH rechargeable batteries that gave me several hours of autonomy. In order to connect the battery holders to the controller, I soldered a two-position female header and insulated the leads with heat-shrink tubing.

I used almost exclusively cable ties to tie everything on the aluminum plate except for the winch servo motor that I screwed in and the long nut that was also screwed in place (after being drilled sideways).  I also had to drill the bottom aluminum face in order to allow for the tripod screw to be inserted into the nut.

Operating it

Panoramic camera in action

This first prototype requires a laptop to be operated, which can be a little annoying.  I plan to use my EeePC in the immediate future and an embedded computer for an eventual commercial kit. It basically works as follows:

1. The camera is set on the panoramic mount, which is fastened to the tripod.
2. The servo controller and the camera are connected to the computer trough their respective USB cables.
3. The controlling program is run.
4. The user waits in awe while the camera takes pictures by itself.

In order to control the hardware, I use a python script that uses my Pololu library and gPhoto in order to operate the servos and the camera respectively. I chose gPhoto since it supports a very wide range of cameras and it is very easy to use.

For now, taking a full 360 panorama takes about 15 minutes. This is a very long time and is mostly due to the fact that my script was hastily put together without care about the performance and in very little time. I will, very soon, post a cleaner version of the code, as well as all the panoramas I took properly processes and in full format, similarly to what I did with my San Francisco panoramas.

Acknowledgements

RobotShop.com

I would like to thank the great people at RobotShop for providing the Pololu Micro Serial Servo Controller, the  ServoCity SPT200 Direct Drive Pan & Tilt System, and the Hitec HS-785HB Winch Servo Motor. This is the second (and hopefully not the last) project they sponsor here at Carlitos’ Contraptions. Without their help, I would have never been able to afford any of the materials (except for those that come straight from the garbage as usual).

They have also being very patient and understanding about my unexpected delay in rolling out this project.

The Opus card is pretty much like an onion
~ Oscar Wilde

Here in Montreal, the public transportation system (STM) started to use a new system for paying the fares: a smartcard.

This smartcard is called Opus and features contactless communication as well as regular metal pads (like those on telephone cards). This card can be recharged with various tickets, month passes, week passes, etc. More info on it can be found in its very own wiki page.

Ever since it came out, I wanted to hack it and learn more about it. By searching a bit on the net, I found out that it is similar to other smart cards being used elsewhere in the world and this allowed me to learn some interesting things.

Similarly to the Hong Kong version of the system, the reader has a security feature that avoids writing to more than one card at the time. Let me explain: if you try to add fares to many cards at the same time (on the paying machine that features a contactless reader) by placing them on the reader, only the first one will get loaded with fares. This means that the cards are more than a simple memory, they feature a more complex and almost certainly encrypted communication system.

Also, each card has its own identification number.

Observations on the card behaviour:

• Cards loaded with a monthly pass will make the the readers shine a green light (or yellow for students) during the given month and grant access.
• Cards loaded with tickets will make the reader say that one ticket has been used, shine a green light and grant access (same behaviour as with alternative magnetic band tickets). The ticket is then spent.
• If the card with a ticket is read again within two hours of spending a ticket, the reader will shine a green light and grant access without spending another ticket. The readers also displays a message acknowledging this.
• The process of loading a card with new fares takes around two seconds after the payment has been performed. While the card is being loaded, a yellow progress bar is shown. This means that writing to the card is a slow operation and cannot be performed on the fly while passing the card by the reader when entering the bus, for instance.
• It is unlikely that the readers in the buses are connected in a network with all metro stations and themselves.

How I think the card works:

1. The card is put next to the reader which provides it with power (same as any contact less communication)
2. The reader sends the current time to the card.
3. The card checks if it can grant access to the transportation at the given time.
1. If it has a month pass, the card only worries to see if the month is write.
2. If it has a ticket it stores the time and spends a ticket.
3. If it has spent the ticket in the previous two hours it does not decrement the ticket count
4. In all the previous cases, the card sends the instruction to the reader to grant access and tells it what kind of message/light it should show.
5. If the card does not have tickets or month passes or transfers (a ticket spent in the last two hours) it less the reader so and the reader does not grant access.

If this card is any similar to the ones in other countries, all the communication between the reader and the card are encrypted. The encryption may be symmetrical which means that there is a secret key shared by all the readers and the cards.

Also, at some point, the card may send its unique ID number to the reader.


Some extra info:
I also wanted to see how the card is built, and the easiest way of doing so is to disassemble it.

Since it is made out of plastic, I put it to rest in a bath of acetone (nail polish remover) for a bit less than a day while periodically checking how it was doing. I poured the acetone in a old iPod metal casing since it has almost the same size as the card.

In the end I found out that the card is made up of several layers. This layers are very thin (or so are they after being soaked in acetone for 20 hours) but very sturdy.

The middle layer contains the antenna and contact pads in order to be connected to the microprocessor. The chip is merely sitting on the pads, this may explain why the cards are so prone to break: when it is bent, the pads do not touch the antenna any more and the the card becomes inactive.

Note that the dissolved plastic in acetone really stinks on the fingers when you manipulate the dissolved card and it is really a pain to clean.

I found a nice breadboard in McGill’s garbage a while ago and decided to convert it into an electronics bench. My main goal was to have a powerful power supply with regulated outputs combined with a breadboard and some useful connectors so I can build circuit prototypes easily. Also, I needed a new bench power supply since mine was lost in the Lunar Excavator shipment.

Materials

• A nice breadboard found in the garbage
• A computer power supply
• An ATX motherboard power connector
• Two LEDs with resistors for current limiting
• A switch
• Some cables

Putting it Together

I wanted to build a modular system so I can replace the pieces easily, especially the power supply (since it comes from an old computer and may not work for very long).

I connected a switch and two LEDs (actually, my switch comes with an integrated light so I used only one LED) to the PS ON, 5V SB, and PWR OK pins so I can have an indicator of the power supply (PS) being plugged-in (D1) and another for the PS being turned ON (D2). The diagram below illustrates the connections.

I also connected the 12, 5, 3.3, 0, -5, and -12 V lines to the bottom-left banana connectors in order to have easy access to the power lines. Now, I can connect any ATX power supply to the box and it will work, which makes replacing a defective power supply very easy.

After making the electrical connections, the switch and LED(s) have to be mounted to the box by drilling appropriate holes.

This was a fairly easy build, with the only difficult part being to find the appropriate materials in the garbage.

I may add a USB hub or some USB connectors as well in order to have more ways of connecting things to the box.