1 Sene önce Shell Eco Marathon Yarışına katıldığımızda Motor sürücülerini Maxon ADS50/10 olarak satın almıştık. 3 Adet motoru sürebilmek için 3 adet te sürücü gerekiyordu. Ayrıca bu sürücüleri kontrol edebilmek için 2 adet PIC16f877 tabanlı kart ve 1 adet te sponsorumuz olan MOXA nın gönderdiği endüstriyel PC lerden olan W341 kullanmamız gerekmişti.
Bu sene ise geçen seneden farklı olarak 3 adet kart 3 adet motor sürücüsü ve bir bilgisayarın yaptığı işleri yapacak olan bir kart tasarlamak istedik. Nedeni gereksiz olarak yer kaplamaları ve kablo karmaşasına yol açmaları idi. Bu sebeble aşağıda Proteus çizimleri bulunan kartı çizdim. Bu karttan ufak ufak bahsetmek gerekirse Fuel cell den cıkan voltaj 40-50 V civarlarında dolaşıyor o nedenle bunu 15V ve 5V a regüle etmemiz gerekiyor ki kart elemanlarını besleyebilelim. Bunu da LM2575HV-5V ve LM2575HV-15V ile yapıyoruz. HV işareti 2575 standartlardan farklı olarak bu elemanların 60V a kadar dayanabileceğini gösteriyor. Aslında bu elemanlar birer buck converter fakat geleneksel buck converterlar gibi ayrı ayrı elemanların toplanmış ve tek bir paket içerisine gömülmüş halleri. içlerinde mosfetleri voltaj referansları pwm cıkışları mevcut. Siz sadece giriş kapasitesi, çıkış kapasitesi, endüktansı ve diyodunu bağlamakla yetiniyorsunuz.
Kartın başka bir bölümüde RS485 Bus sisteminin kartın değişik sistemleri arasında haberleşmeyi sağlayacak kısmı. Bu kısımda kart üzerindeki her bir cpu yu bus a bağlayan bir RS485 Transreceiver bulunuyor. RS485 Diferansiyel bir bus olduğundan ve elektriksel olarak PIC MCU ların verebildiğinden farklı bir elektriksel işarete ihtiyaç duyduğundan bu şekilde bir ceviriciye ihtiyac duyuluyor. RS485 bus hakkında daha fazla bilgi almak için tıklayın. Bu bus üzerinden hangi motorun nekadar akım cektiği Fuelcell voltajı LCD de gösterilmesi gereken bilgiler vs. gibi datalar geziniyor. Bu datalar bir mcu tarafından gönderildiğinde diğer tüm mcu lar tarafından alınıyor. O yüzden sadece kendilerini ilgilendiren bilgilere cevap verebilmeleri için gönderilen datanın ne ile ilgili olduğununda bus üzerindeki veriye eklenmesi gerekiyor. Bunun için $#senderid#dataid#datalen#data#crc16#$ şeklinde bir data formatı kullanılıyor. sender id datayı gönderen MCU nun kendine özel tanımlama kodu. Örneğin Motor1 in MCU su data gönderirken senderid yerine 0x10 yazıyor. Dataid ise gönderilen datanın ne olduğunu tanımlayan bir byte örneğin LCD kontrol kartı aynı zamanda Fuelcell votlajını da ölçüyor bunu gönderirken de 0x12 kodunu kullanıyor. Fakat bu datanın her bir motor kontrol MCU su tarafından kullanılması alınması gerekiyor. O yüzden dataid de 0x12 gören Motor MCU ları bunu alıp kullanıyor. Datalen ise datanın kaç byte uzunluğunda olduğunu gösteren bir byte.Bu uzunluğun içerisine crc16 hesaplaması dahil değil. CRC16 ise datanın gerçekliğinin (düzgün alınıp alınmadığının) testinin yapılmasını sağlayan 2 byte uzunluğunda bir veri. CRC16 hakkında daha fazla bilgi için tıklayın.
3 adet motorumuz var dedik. Motorların üçüde aynı dişli üzerinde bağlı olduklarından tamamen aynı hızda dönmeleri gerekiyor yoksa birbirlerini frenleyerek boşu boşune enerji harcarlar. Bu da istenen bir durum olmadığı için motorların hızlarını kontrol edebilmek için PID algoritması kullanıldı. Peki motorların hızlarını ölçmemiz gerekiyor bunun için ne yapabiliriz. Bunun içinde encoder kullanabiliriz. Maxonun MR32 encoderları bizim için yeterli olacaktır. Cizime bakarsanız Encoderların sadece 1 kanallarının işlemciye girildiğini göreceksiniz. Bunun nedeni de motorlar sadece 1 yönde dönecekler yarışta geri geri gitmek yasak olduğu için bu şekilde oluyor :). Ayrıca ikinci kanalı işlemciye girersek boşu boşuna (kullanmayacağımız halde) kesme üreterek işlemcinin yapması gereken işleri yavaşlatmış oluruz. Ayrıca cizimde m1tom2 m2tom3 m3tom2 m2tom1 şeklinde bağlantılar gözüküyor. Bu bağlantılar ise motorların zorlandığı durumlarda logic1 yapılarak diğer işlemcinin uyarılmasını sağlıyor (m1tom2 m2tom3). Aynısı ama tersi şeklinde m3tom2 m2tom1 de motorun zorlanmasının sona erdiğini ve gerekirse bir önceki motoru kontrol eden CPU tarafından motorun kapatılabileceği sinyali için kullanılıyor. Pekala bunları RS485 bus üzerinden de yapabilirdik fakat niye yapmadık?. Çünkü RS485 bus kilitlenebilir ya da bir şekilde parazit alıp bütün motorların aniden devreye girip aniden devreden cıkmasına neden olabilir. O yüzden RS485 bus ile bunu yapmadık. Ayrıca her üç motor MCUsuna giren Pot isimli bir giriş gözüküyor. Bu giriş pilotun elinde bulunan bir potansiyometre ile motorların hızının ayarlanmasını sağlıyor. Her üç MCU da da bu analog girişlere bağlanmış durumda ve 10 bit digital olarak ölçüm yapılıyor.
Son olarak motorların sürücü tarafı. Yani power katmanı. Bu katmanda MCU dan alınan pwm tc4422 olarak secilen yüksek hızlı yüksek akımlı low side mosfet sürücü tarafından mosfet e besleniyor. Ayrıca toprak tarafından gözüken 0.024R lik direnc akımın ölçülebilmesi için kullanılıyor. Fakat bu direnç üzerinde oluşan voltaj çok düşük mV seviyelerinde olduğu için önce opamp ile yükseltilmesi gerekiyor. Bunun içinde AD820 olarak secilen yüksek hızlı rail-to-rail opamp kullanıldı. PWM ve opamplar hakkında daha fazla bilgi için isimlerinin üzerine tıklayın.
Sunday, November 2, 2008
Hyd-R X Motor Driver & Controller
Posted by
Levent Komurcu
at
5:49 AM
0
comments
Thursday, July 3, 2008
USB ?
I was looking for usb implementation for a project that i have been working for about 3 weeks and i came up with this those are the thoughts i have but somebody writen down them already :).
In 1962, a group of brilliant engineers have postulated the RS232 serial communications protocol, and until 1998 everybody worked with this communications channel very well. It was present on all PCs, until recently. Today, if you will check the newest models of computers on sale, you are going to discover more than half of the tower/desktop PCs do not have the serial RS232 connector (DB 9), and for certain no laptops have it. This is due to a group of only seven companies: they have figured out they can easily milk more money from users and developers, if they force the implementation of a “better” alternative to the old RS232.
Things are this way. A communications channel should be just what it is: a simple hardware communications channel. Each software routine or hardware module should be capable of accessing the communications channel easily, just by configuring it, and this is exactly the case of the RS232 protocol. Since 1962 millions of applications have been written based on RS232 serial communications, and some of them are technical, unique and very expensive. According to the most basic rule in the digital world, which says “backwards compatibility”, it was logic and natural that RS232 was going to be upgraded to higher speeds, and smaller interface connectors. Unfortunately, logic does not sell very well these days.
The reverse of the good, decent logic says: “Why not make the serial communications channel very difficult to implement? Let’s make that communications channel driver so difficult to implement that people would be glad to pay money to have it already done. In addition, we could make this new serial communications channel strictly dependant, so that it will work only on one particular version of Operating System; for different OS versions, they will have to pay more money! Even more, if somebody is smart enough to develop this new serial communications channel driver, then that person or company will have to pay an annual subscription fee of, say, 10000 up to 20000 USD, in order to sell his or their products.”
“Wait a minute; we can also sell a unique code number with each new driver, named ‘Vendor’s Code’ so that only the big companies are going to afford getting one. The medium and small developers, and the public eventually, will have to pay for it!”
“Could we make it worse?”
“Yes, we can take out all ‘free of charge’ RS232 connectors, from all PCs, so that everybody will have to implement the ‘better’ communications channels. Ha, ha!”
“Can we make it even worse?”
“Yes, we do have many possibilities to make it worse, but we will implement them gradually, one at a time, so that our new source of wealth will never dry out!”
“Now, to add insult to the injury, I suggest naming the new communications protocol “universal”: the Universal Serial Bus!”
“Ha, ha, ha!”
A communications channel it is just like a necessary tool: you grab it and work with it, then you put it back where you took it from. You do not need to work for 3 or 4 months to develop a “driver” for that channel--nobody did it with RS232. Today, implementing USB communications in a small project it is more demanding that the project itself, for most applications, and it is so expensive that small and medium developers cannot afford doing it: they have to buy USB drivers from “qualified-vendors”!
Sure, the qualified-vendors are also selling RS232-to-USB adaptors, but this is still lots of extra costs added to the totally free RS232 interface we had. However, what is really alarming is, the trend is to eliminate any trace of free communications channels, from all PCs! With little efforts today, the international community of developers and IEEE could get together and reinstate the old RS232 serial communications channel, based on an upgraded and (easily) backwards compatible new RS232 protocol. This is not very difficult and I offer my help.
Please note; besides from being intentionally very difficult to implement and costly, the USB protocol it is a proprietary one. That group of seven companies I mentioned has a license on it! This is not right, because PC architecture it is public domain, and same is the old, reliable, RS232 serial communications channel. They belong to all of us, and it is our right and duty to protect public domain from being stolen. If we do not defend our rights, now, rest assured we are going to see more parts of our PCs becoming the property of few groups of companies, one by one.
O G POPA is Professional Engineer in BC, Canada. His home site is Corollary Theorems at http://www.corollarytheorems.com
Posted by
Levent Komurcu
at
1:36 PM
0
comments
Sunday, January 13, 2008
HYD-R
I have been looking for our last years race videos and i remembered that i friend of mine posted a marvelous video shot of HYD-R from time trial runs. After that shot ( Approximatly 1 min later) that car was crashed and turned upside down. No injuries, car was still working. Here is the video.
Posted by
Levent Komurcu
at
5:43 PM
0
comments
Telemetry System Updates
I have'nt been writing for a long time thus i will give a update about telemetry system.
Telemetry System's monitoring app is nearly finished ( just a few hundred lines missing :)). I have finished telemetry systems GPS, RS232 communications, RS485 Communications and GSM modem threads. But there is a problem with Moxa's IOLogic 4000 Series library not being compitable with W345 Embedded Computer. So Moxa is working on this issue. I hope they can finish before Shell Eco Marathon.
I have switched to the telemetry system for HYD-R which is formly a hydrogen powered vehicle beacuse of lack of time to finish barracudas telemetry system and port them to hyd-r. So after finishing HYD-R telemetry I will port it to Barracuda.
You can view photos of HYD-R and Barracuda HERE.
Posted by
Levent Komurcu
at
5:28 PM
0
comments
Labels: gesk