Efika 5200B Project Embedded Systems Portability in category Embedded proposed by Charles Jarvis on 1st March 2008 (accepted on 1st May 2008) Developers: Charles Jarvis, Kevin Nickels

Project Blog Entries

	Another update... posted by Charles Jarvis on 2nd August 2008 This will probably be my last update to this project. The summer program at Trinity has ended, and as I have graduated, I've found a job in Houston and start later in the fall. So for this blog, I'll give an overview of what we've accomplished this summer in the lab at Trinity. The robot arm controller is in a stable, finished-for-now state. It can control 5 motor independently, all 5 at once or one at a time. Shown above is the block diagram in Quartus that runs the motors. It's main components are an address decoder/memory controller, a PWM generator, a logic module, and an 8-bit register for memory. If you want to read the manual/report on the arm controller, it can be found here. Above is the interface board hooked up to the arm and the DE2-70. We used wire wrapping for prototyping, so that it would be easier to rearrange things if necessary (and it was). One thing we didn't get finished however, was a P controller of position for the arm. We have the sensors (one of them is shown below), but we weren't able to get around to mounting them, so we couldn't test the code we developed for the P controller. However, later in the fall/spring, Dr. Nickels will probably be hiring a current student to do some more work on the project(s). The other project that was (mostly) finished this summer was the update of our Instron 4201 machine, which has been mentioned in earlier posts. The operating manual for the Instron and its VI can be found here. However, we did not get to where we wanted to on this project due to never being able to obtain the Efika/QNX/LabView machine from National Instruments. You may have also noticed that there hasn't been much in this blog actually dealing with the Efika. That's because my strong point was working with digital logic, and not the Linux/hardware side of things. We are also bringing in someone during the fall to help us with finishing up the labs as well as help us get the interface between the Efika and the CPLD/FPGA PCI cards working. [Permalink]

	More Progress posted by Charles Jarvis on 9th July 2008 Since the last update, we've made a good deal of progress. Last time, we had the motor driver hooked up to a couple of switches and a few logic gates as a simple prototype. Now, the system is controlled completely digitally, save for the motor driver which can't be implemented in VHDL (we don't want to release the magic gray smoke inside the Cyclone II chip). The first picture below shows our current setup. As can be seen in this picture, we have the breadboard with the SN754410 on it, now connected to one of the expansion ports on the DE2-70. The ports on the expansion slot are controlled by the program shown below. Right now, the program only controls one motor but that can be easily expanded by simply copying, pasting, and changing a few numbers and letters. In the background of the photo, next to the breadboard, is an upside-down prototyping board, generally used for soldering. Instead, we are using wire-wrapping so that we have a semi-permanent prototype. The only problem is easily locating connectors made for wire-wrapping since the technology has mostly been phased out, but electronics surplus stores generally have them. The reason we are using wire-wrapping is because way too often, many senior design projects at Trinity come to an end with their final prototype still on a breadboard. Not everyone knows how to solder, or is good at soldering. I didn't learn how to solder until this past school year, when I needed to make a sturdy prototype for my senior design project. I'm mediocre at it, but I'm a lot better than I was a year and a half ago when I was so inept with a soldering iron that I burned my right pinkie pretty good and nearly dropped the iron right into my lap. But that said, wire-wrapping is a good middle ground since it's more permanent than a breadboard but doesn't have the learning curve that soldering has. This is the "program" that controls the motor. The program has four modules it uses to operate (it should evident which one is which): A clock divider that takes the 50MHz system clock and divides it down into decades starting at 1MHz, a RAM module for memory, a PWM generator which uses a 20ms cycle and allows pulse widths from 0ms to 20ms, and the logic circuit used to turn braking and direction signals into signals that the SN754410 can use. The PWM generator uses the toggle switches on the DE2 for input. Since we wanted to have the full range of 0ms to 20ms available to us for use, we had to use 5 bits for data. Since this allows for numbers up to 31 (11111 in binary), there is a line of VHDL code in the PWM module that caps the high-time value at 20ms, even if it is being given a value greater than 20 (confusing enough? :) ).The big accomplishment this week was adding addressable memory to the system. Its data input is the 5 bits for pulse width high-time, 1 bit for braking, and 1 bit for direction. Different presets can be applied to different addresses in memory, thus allowing for fast switching between low and high speeds in different directions. Currently, the input method used, as mentioned before, is the toggle switches and push-buttons on the DE2. The first 8 switches (7 to 0) are used for PWM-Brake-Direction input, the next 4 (11 to 8) are used for the address, the leftmost push-button is used as the write-enable for the RAM, and the rightmost push-button is used as the enable for the PWM generator. Eventually, this will be controlled via PCI, which is the supreme goal for both the robot arm and the visible motor. The nice thing about controlling everything this way is that the code is very easily ported between mechanical systems. Since we're using DC motors in both instances, I can use this exact same software to control the DC motor mounted to the model motor. Of course, in that case, a single MOSFET will be used as opposed to a full-fledged H-Bridge IC, since the model motor will be using only one DC motor and will have unidirectional rotation. The other good thing is that we now have both of our PCI Dev Kits in. Seen above is the MAX II PCI development kit mounted and operating with the Efika. Now we just need to write some code on the Efika end and we should be up and running. The Cyclone II PCI Dev Kit doens't fit inside the OpenClient case so we're going to work on fixing that by getting a PCI riser and mounting the Cyclone II Dev Kit on top of the case. [Permalink]

	Pictures posted by Charles Jarvis on 1st July 2008 We got the Altera PCI dev kit in today, so work will start on that soon. So that said, here are some pictures of our projects in progress. First is our new standalone development board. Across the top, you can see that it has USB input, Firewire input, Mic/Line IN/OUT, 2 RCA Video inputs, VGA output, an Ethernet connection, an RS-232 connection, and an SD Card input on the bottom of the board (not in picture). Most of these features won't be used in the courses here at Trinity, but if I have some downtime anytime soon, I plan to play around with alot of the fancier features, get them working, and document them. Second is the model motor we will be using. As soon as our machine shop technician gets back from vacation next week, we will have a mount built so that a DC motor can be mounted to drive the crankshaft. Third is the robot arm we have built. It has 5 DC motors to control it's movement: One at the base which allows almost 360 degrees of rotation, three at each joint on the arm, and one to control the clamp at the top. Sometime this week, we will begin to place sensors on there so that we can grab position measurements. On the bottom right is the logic and driver for one of the motors. The plan is to implement that logic in VHDL and put that on to our DE2, and put two more SN754410 chips on there so that we can control 5 motors easily. Fourth is the Altera PCI Development kit we just got in today. One immediate hurdle we have to overcome is fitting this thing inside one of the OpenClient cases. It's physically too big to fit in the cases we have. Also, there is an extra set of "pins" (or whatever the proper name for the PCI connectors are) on the bottom right side of the board. This may be for PCI Express, but we'll have to research that before taking a saw to our equipment (These PCI dev kits are about $1000 each). [Permalink]

	Progress posted by Charles Jarvis on 30th June 2008 It's been a month and we've made quite a bit of progress with our projects. I. Instron Strength Tester This was one of the first projects to be worked on this summer. For the past 25 years, the Instron 4201 in the Trinity Machine Shop was run by an IBM PC XT, which ran a $10,000 software package made by Instrong specifically for the 4201. Because of the high cost, it was never updated (nor did it need to be, since the only upgrade would be a prettier interface). Our aim is to replace the old system with a LabVIEW VI run on an Efika OpenClient/QNX package available from National Instruments. Most of the LabVIEW work was done this past spring semester by one of this years graduating seniors, Alexandra Miller. Now all of the kinks are worked out and a few more features--such as raw data formatting, plotting, and important material property calculations--have been added, so the VI is nearly ready for student use come August. However, progress has somewhat stalled with the OpenClient/QNX package, so the system is temporarily running on a Dell PC. Alot of the QNX work was done by an NI intern who we're trying to get in on the project. II. Controls Projects One of our other projects is to use a PCI-capable FPGA to interface with/control a set of "plants." However, the PCI-capable FPGAs are on backorder from Altera until August, so in the meantime, we will develop the control systems and interfacing with a standalone Altera development board. Two of the plants have been constructed. The V8 Model Engine was completed last week. Now it needs a DC motor mounted to it so that we can control speed via a MOSFET. The robot arm was finished a couple of weeks ago and we have made interfacing for it. We used an SN754410 Quadruple Half H-Bridge (it's a mouthful) as the motor driver and built a logic circuit that provides a layer of abstraction for the student. The system has three easy inputs: PWM, Brake, Direction, which can be easily controlled from an FPGA. We also have a brand new Altera DE2-70 FPGA development board which will replace the old Altera UP2 development boards that we've used in the past. Most of this past week has been spent getting accustomed to the new board, since it is far more powerful and has many more features than the previous boards. Pictues of everything will be up in a couple of days. [Permalink]

	Progress on 'The EFIKA Lab' posted by Kevin Nickels on 4th June 2008 One way to summarize the project would be to say that we're bulding an EFIKA lab at Trinity. If you read the description, you'll see that we're actually making a half-dozen demos of "different ways to control things". So we've got say a toy model engine - how to control the speed? You could have an op-amp circuit with a cap and resistor (PI control). But setting the setpoint or change gains is fairly manual. You could have a microcontroller (e.g. OOPIC) with an H-bridge, now changing the control scheme or setpoints is software. But that's about all this controller can handle - think about moving to a 6-axis robot arm. Now it's not enough (not 6 timer/counters to handle encoders, motor synchronization, etc...) With some analog/digital electronics interfacing, we could design a circuit to do this, inside an FPGA (Field Programmable Gate Array). Same problem as op-amp WRT control, though. Now, what if we could, using a computer, do things like change the control gains or setpoint? With a PCI-enabled FPGA and an EFIKA, we think that we can do this. Better yet, we're also going to do it with a lower-power computer and a lighter-weight FPGA/CPLD. Stay tuned. [Permalink]