Category Archives: electronics

Design of a 2-axis, Continuous Rotation, Camera Control Platform

Posted on by
17

This was the title of my final year project for my BEng (Mechatroics) degree at the University of Stellenbosch. It’s been a year, a loooong year, but at the same time it’s passed so quickly. I’ve probably spent more time on varsity work this year than in any other previous year, a combination of this skripsie, mechatronics and electrical design projects, interspersed between the year’s class requirements.

You can see a summary poster of the project here. And the full report here.

Skripsie is something very different to what we’ve done previously. We’re given a year to complete the project, which is a fairly long time. What I’ve appreciated is the fact that it’s the only major project we’ve been given to do individually. It’s not that I don’t like other people, it’s just that it’s sometimes nice to be able to do things my way. Most of the projects are put forth by lecturers, and they act as supervisors for the projects. I’ve been very fortunate with my supervisor and his continued support and enthusiasm for my project.

Final Product

Final Product

So what is it? Well it’s basically a turret that is capable of continuous rotation. You get a bunch of pan/tilt cameras on the market, but they all stop after 360textdegree or less. The department I did my project with had purchased several Basler a311fc cameras to play with and desired a platform they could use for tracking. It’s a very nice camera, good quality and capable of fairly high capture rates (50fps @ 640×480, 132fps @ 320×240) and comes with some nifty software (Basler Pylon Driver) to control it. So the major issue was to transfer data and power to the camera. I looked at a couple of wireless solutions but for simplicities sake eventually went with slip rings. Picked up 2 slip rings (at quite a cost, well I was surprised at the expense) from Moog.

a slipring

a slipring

Next issue was control. My control systems has never been the strongest, so decided to stick with some open loop control in the form of stepper motors. Picked up a 220Nmm and 440Nmm stepper motor to control the tilt and pan respectively. They’re bi-polar hybrid stepper motors with a 0.9textdegree step size. I drove them both in half-step mode effectively giving me 0.45textdegree accuracy. To drive them I made use of a combination of L297 and L298 ICs from ST.

The idea was to be able to control this all from a PC, so some software development and integration was also required. To bring it all together I made use of an Arduino Uno. I developed a GUI in Python which then communicated via a serial connection with the Arduino. I was originally going to use Java for this, but couldn’t get a serial connection running. Chatted to some friends who suggested Python and found this post with a nice example. For testing I also got hold of two AS5040 hall effect sensors from Austria Microsystems. These rotary encoders give a 1024bit resolution, effectively 0.35/textdegree. I managed to find some nice code for the Arduino to read the data via SSI over at RepRap.

CAD Model

CAD Model

This was also the first time I’ve had the opportunity to develop CAD models of something and have it built. We’ve done several machine design projects over the years, but they’ve all been conceptual only. I didn’t machine the stuff myself, but it was pretty cool when I built the thing, and compared it to my model, and it looked the same.

screenshot of the UI

screenshot of the UI

So I handed in the final report on the project today. Unfortunately it’s not working 100% at the moment, and one of the motor driver circuits got damaged, so I need to repair that before my presentation in a few weeks time.

But until then, it’s 3 exams in 3 weeks, so ought to be pretty chilled. And I’m almost an engineer o/

Busiest & Best

Posted on by
Reply

This last semester has kept me busier academically than I’ve ever been before with the main culprits being our two large design projects as well as skripsie. And when i say busy, I mean spending hour after hour through weekends and public holidays in labs working to ensure that projects are complete. The thing is, is that I was having fun. Well to an extent. There were many times where tiredness and frustrations got the better of me, but the moments of joy when something worked were incredible.

The Mechatronics project was interesting, but not my favourite. In theory it was quite simple, but a bit more tricky in application. In essence we were told we needed to take 2 tanks and then have user inputs allowing one to set the desired water level and temperature in both tanks. We were limited by only being able to pump fresh water into tank 1, and only being allowed to place a heating element in tank 1. Our end setup comprised of a kettle as our first tank which we pumped fresh water into. The second tank was placed at a lower height to allow water to flow from the first tank to the second tank. Water could be pumped into tank 1, and then solenoid valves were used to allow water to flow into the second tank, or allow water to flow from either of the tanks back into the reservoir.

Floats were connected to potentiometers to give us a height/volume reading of the water and supplied thermocouples gave us accurate temperature readings. The entire system is then linked by a Schneider Electric Modicon momentum Soft PLC and Tutorbox. During the term we were given tutorials on how to use Wonderware’s InControl and InTouch software to control the PLC. The project does rather throw one into the deep end though. The training for the PLC doesn’t really explain it’s functionality and very little focus is given on actually programming in the software. Instead we’re taught to make use of RLL programs to control the system.

But the scope of our project was far too complicated to rely on RLL programs. Instead we chose to figure out how to use the other supported Structured Text Language instead. We downloaded some tutorials and beginners guides, but so many of the things we tried gave us compiler errors in the software, so in the end we resorted to a trial and error method, hacking our way through. Till now I’ve only ever really coded in Objected Orientated programming languages, which I don’t really feel STL complies to. This amongst with many other small nuances lead to me hating the programming side of this project. Fortunately one of the group members took to it with vigour.

Our final demo went reasonably well, everything worked to an extent and the “judges” seemed impressed even if the system didn’t run as smoothly as we had hoped.

And onto Digital Design. The basic story is that we were building remote controlled gate units. We had a main board which comprised of a 16 character LCD screen on which we displayed a menu controlled by 5 push buttons. There was a serial->USB converter to communicate with a computer, some EEPROM to store some data a PWM controller to control the “gate” motor, an optical sensor for determining the state of the gate, a triac to turn an AC driven light on/off a buzzer to annoy people and an IR receiver.
We then had a remote with an IR diode for transmitting data, 2 buttons and its own EEPROM for good measure. Both units were based around the Renesas R8/C27 microcontroller programmed in C via Renesas’ HEW software. Fun with that spawned this fan group page. Apart from a few resistor values that had to be calculated, the component design aspect was pretty much handled for us, the big issue was understanding how these components worked, and then getting them to play nice with the rest of the components.

We were given the components every 2nd week or so, and built up our boards slowly as we acquired and programmed each successive piece. In the end we had a board on which each component worked by itself, but then it was time to pull everything together and get the software programmed to work as required. Quite a challenge. This was truly the subject which has taught me the most, or in which I feel I’ve learnt the most. It was work that I hadn’t ever really done, but had always interested me, and although it really is a tough course, and a bit of a trial by fire, I’m glad how it turned out.

As an interesting fact, last year somewhere close to 50% of 4th year Mechatronic Engineers failed the subject. And I can believe that. Although we are given some preparation in the form of a semester of Electronics and 2 semesters of Computer System, the work we do is completely new and requires a different way of thinking and time dedication second to none.

A friend of mine described the subject like this: “Ontwerp n hekmotor en remote. Hier is so 3 bladsye se totally vague instructions, ons sal julle een keer n week kom se presies hoe ver julle agter is. O ja, hier is 6000 bladsye se inligting waardeur jy moet soek vir een pin se default state. Rinse and repeat so 30 miljoen keer. Elke dag”. Roughly translated it is: “Design a gate motor and remote. Here are 3 pages of completely vauge instructions. We’ll come tell you once a week exactly how behind you are. Oh yes, here are 6000 pages of information that you have to search through to find one pins defaults state. Rinse and repeat about 30 million times. Every Day.”

Although a bit dramatic, it quite often feels like. Nothing has frustrated me as much as the unproductive hours spent on this project. We’re busy compiling a report on the project to hand in on Monday, so will post some schematics and pictures then.And then it’s on to exams for 3 weeks, a bit of holiday/skripsie work for 2 weeks, vacation work in East London for 4 weeks and back to Stellenbosch for my last undergrad semester.

DSTV and flashing lights

Posted on by

EDIT: For some reason I’m getting a lot of hits on this page at the moment, it only addresses one element on one decoder. If you have any other hassles with your decoder check out this link.

I went home this evening for a family get together and walking into the TV room I noticed an annoying flashing orange light on our Multichoice DSTV decoder. Although others had noticed it, no one knew anything about it. While browsing through some channels my sister pointed out a small “letter” icon which had popped up in the one corner of the screen. Going to the menu and opening the “Mail Messages” option gives one a brief notice about new terms and conditions relating to Multichoice. It also stopped the flashing light.

Mentioning this to my Dad, he told me my Gran had been complaining about the light too, quick phonecall to her and problem solved, along with a set of instructions she was to pass on to her friends.

Now I like the way that Multichoice have integrated this feature into the system, it’s just a pity that I doubt anyone actually knows about it. I’m also very curious to know how many phone calls the service centre got about this flashing light that just started randomly last week.

So for anyone wanting to get rid of the flashing orange light:
Turn on your TV and Multichoice Decoder. Take your remote and push the bottom left “Menu” button. A menu should come up on your screen, scroll down to the “Mail Messages” option (if I recall it was option 4) using the cursor/arrow buttons, and use the select button to go into the Mail Messages. It should display a message with regards to the new terms and conditions. Once read, the light should stop flashing and you can press the white “Exit” button once or twice to resume your viewing.