Test rig for CAN-bus testing

Today I made a mount for two gauges to keep them in place while I do CAN-bus testing.
And it is much nicer to watch them when they are not just a pile of electronics on top of spaghetti of cables and wires.
See?
And hiding behind that maple-stained polyurethane finished oak plywood is the brains of the gauges.
Oh yes, this is the "cockpit R&D department" of Dallasin Porkkanasorvaus...


And here comes "dummy demo" showing the operation of both gauges simultaneously.
Tomorrow, I hope, I can test CAN-bus and control there gauges from PC.



Stay tuned. I have feeling that this system is really starting to take shape from now...

Next one coming...

Airspeed indicator in progress.
Again pointer movement is choppy due to video equipment.




I think next I will start integrating the tcp-stack to system.
Or perhaps I will do altimeter. It needs two continuous rotation servos, some kind of position sensing for pointers and some gearing...

Here is an action shot of version 1.0 of the "final" mechanics design of singe pointer gauge.

If you watch carefully, you can say there is about 0.5mm free play in gears...
Movement of the pointer is smooth in real life, my videocameraphonethingamajig makes it look choppy in video.

I think next gauge will be more accurate and I will also add functions to correct slack in software.



Let's see. The current status of project is:

CAN-bus

• Signaling/message sending ok
• Messages need to be defined, 50% done
  

Servo control

• One servo control ok
• Multiple servo control 80% coded
• Continuous rotation modifications for servos studied and tested to be working
  

Rotary encoder

• Reading encoder ok

Continuous rotation sensor (for continuous rotation servo position detection)

• Reading value through AD-conversion coded
• Sensor has about 60degrees where the value is random, needs to figure out how to use two sensors in one axle to get accurate readings.

To Do

• Count how many servos need to be modified for continuous rotation
• Modify servos
• Build mechanics for the rest of gauges
• Draw schematics and layout for gauge control board
• Integrate tcp-stack to master control board sw
• Start designing radio stack
• etc.
  

After long development...

Here you can see my latest, and best so far, contraption for gauge mechanics:


Servo is just a regular non-modified miniservo, rotates 200degrees. 10:1-gearing makes the needle axle rotate 2000degrees (about 5.5 rounds).

Most of the gauges do not need that many rounds (variometer, tachometer, air speed etc.) and some of them do need infinite rotation of the needle (altimeter etc) so I still need to either modify servo for continuous rotation or perhaps I could use small stepper motors (that was the plan earlier in this project).

I am not especially proud of this achievement...

Took me many days to get servo control working properly.
But now it works and I can concentrate to messaging between master board and instruments.
Pah!
With my background this should have been a piece of cake.
It is like this when you get older.



Of course everything above is just a joke. Servo control and timing works now properly so I
can move to other parts of code.

Let's see...

Stepper control [x]
Servo control [x]
Rotary encoder reading [x]
i2c bus messaging [x]
eeprom reading/writing [x]

Looks like instrument coding is getting there. Oh yeah!

Stepper motors etc.

Howdy again.

Due to numerous requests (=1) I have decided to change the language of this blog to english.

Ok, the status of the project is:

Software, done:

• i2c master-slave messaging is working properly. Needs proper messaging to be defined though.
  
• Stepper motor control is finetuned
• "Calibration" (setup) of stepper motor driven pointer is coded
• Functions driving pointer to point desired value have been written. And it works. Almost.
  
• Reading of one rotary encoder works ok
  

Software, next:

• Control functions for servos (3)
• Add another rotary encoder reading
• Start coding ethernet - i2c "bridge"
  

Hardware,next:

• Still looking for cheap stepper motor with very fine steps (more than 100/revolution)
• Get one of these for ethernet-i2c-board
• Figure out the stepper motor current limiter system
• How to find the "home" position of pointers? Hall-effect sensors or optical interruptors or perhaps something else?
  

Mechanics, considerations:

• Print gauge backgrounds, buy one Simkits kit (comes with tens of backgrounds) or buy real instruments from boneyard?
• Use real instrument casings or buy 3" plastic pipe from hardware store?

For stepper motor consideration, here is my current selection of motors.
From left:

• STH-39D191, assumed to be 1.8degrees version. Othervise very nice but quite big.
• PF35T-48L4, about 48 steps per revolution. Makes pointer movement very choppy. Cheap and big.
• QH4-4205 from old printer. Very small, makes motor control IC _very_ hot, needs current limiter reconfiguration. Very small = could put three of these to, for example, altimeter.
• Background: Expert SL300-servo for VOR and ILS.
• Tomorrow I will go to local Fry's electronics and buy one 3.5" floppy to see if it has a stepper motor in it. $4.99.
  

Askelmoottorinohjausta ja kalibrointia

Nyt kun alkoi hommat skulaamaan niin ei meinaa malttaa nukkua ollenkaan...
Siistin kytkentaa ja johdotin mukaan 2kpl MC3479P-askelmoottorinohjauspiiria.

Alkaa pikkuhiljaa hahmottua minkalaisia viesteja prosessorien valilla tulee singahtelemaan. Yksi niista tulee olemaan "setup" jolla hanskataan mittarin kalibrointi.
Tai siis kalibrointi on vahan vaara sana, sanotaan mieluummin "viisarin kohdistus".

Allaolevalla kytkennalla testailin kohdistusfunktioita ja hyvin tuntuu pelaavan.
Homma hoituu talla hetkella tallalailla:
1. Virta paalle
2. Prosessori huomaa jotta viisaria ei ole kohdistettu
3. LCD:lla lukee "zero" -> nuppia pyorittamalla viisari nollakohtaan ja valkoisella napilla kuittaus
4. LCD:lla lukee "min" -> nupilla viisari pienimpaan nayttamaan ja napilla kuittaus
5. Viisari pyorahtaa takaisin nollakohtaan
6. LCD:lla lukee "max" -> nupilla viisari suurimpaan nayttamaan ja napilla kuittaus
7. Prosessori laskee montako askelta moottorin pitaa pyorahtaa per mittarin yksikko


Seuraavaksi (huomenna?) pitaa koodata tuo yllaoleva toimimaan i2c-vaylan yli eli kaskyt ja ohjaukset tulee varsinaiselta ohjauspiirilta eika nupilta ja napilta.

MC3479-piirien virranrajoitusvastuksiakin pitaa ihmetella, pakkaavat naas lampenemaan moottorit ja piirit. Liikaa virtaa. Kevyt muoviviisari ei paljoa virtaa tarvi liikkuakseen.

Mitas tassa viela pitaakaan speksata ja koodata?
- Servojen ohjaus PWM:lla
- Servojen "kalibrointi"
- i2c:n yli heiteltavat komennot
- mita muuta?

JiiHaa!

Toista viikkoa sita sai yrittaa mutta nyt toimii (melkein...).
Eli suunnitelmissahan on laittaa jokaiseen simulaattorin mittariin ja laitteeseen oma mikroprosessori hanskaamaan laitteen toimintaa.
No luonnollisesti nama laitteet pitaa saada keskustelemaan keskenaan, ja siitahan se koko ongelma sai alkunsa.

Nyt sitten, Jannen suosiollisella avustuksella, saatiin prosessorien valinen liikenne toimimaan ainakin toiseen suuntaan. Eipa siina mennytkaan kuin reilu viikko ilta/yohommina paata poydanreunaan paukutellessa.

Edellisesta kuvanotosta on tahan kytkentaan tullut mukaan yksi piiri eli alareunassa nakyva toinen mikrokontrolleri (Microchip Pic 18F2550):

Systeemihan toimii siten etta kuvan alareunassa olevalla kytkentalevylla oleva Pic lahettaa i2c-vaylan yli esimerkiksi sanoman "1350ft" jolloin isomman levyn ylareunassa nakyva toinen Pic komentaa vieressaan olevaa MC3479A-moottorinohjauspiiria siirtamaan viisarin nayttamaan 1350 jalkaa merenpinnasta.

Viela kun saadaan toinen suunta tassa keskusteluyhteydessa toimimaan niin voinkin alkaa koodaamaan varsinaista mittarinohjaussysteemia jossa yksi prosessori kertoo mittareille mita pitaa nayttaa.

Tammoista tallakertaa, toivottavasti kohta lisaa asian tiimoilta, vaan nyt maksamaan univelat Nukku-Matille.

Ensimmainen postaus tahankin blogiin

Vaikka projekti on ollut pyorimassa jo vaikka ja kuinka.

Noh, enivei, kyseessahan on siis kotitekoinen lentokoneen ohjaamo eli tassa tapauksessa simulaattorikayttoon suunniteltu systeemi.

Jarjestelman toimintaperiaate pahkinankuoressa:

PClla pyorii lentosimulaattori(peli...) joko Microsoftin tuote Windowsissa tai X-Plane Linuxissa.
Simulaattorisoftasta kaivetaan tietoa mm. mittaritiedot ja varoitus- yms. valot jne.
Simulaattorisoftaanpain tungetaan tietoa mm. ohjainten ja erilaisten kytkimien asennosta.

Talla hetkella rautapuolella homma on paatetty hoitaa seuraavasti:

• Mittareita ja muuta rautaa ohjaa Microchipin PIC 18F2550-mikrokontrolleri
• Mittareiden viisareita pyorittelee askelmoottorit ja RC-servot
• PClta ohjaus hoidettaneen USB-liitannan kautta joko siten etta jokaiselle laitteelle tulee oma

USB-liitanta tai siten etta tieto kulkee yhden USB-liitannan kautta jarjestelmaan ja sisaisesti
tietoa kuljetetaan SPI-vaylan kautta. Homman voisi myos hoitaa ethernet-verkon kautta
eli voi olla etta talta osin suunnitelmat viela muuttuvat.

Tassa kuitenkin tamanhetkinen piirrustus aiheesta:















Alustavaa kyselya varsinaisesta ohjaamosta on jo tehty paikallisella lentokoneromuttamolla.

Systeemin tilanne talla hetkella on seuraava:

• Mittareiden ohjaus askelmoottorilla:askelmoottorin ohjaus koodattu
• Koko systeemin ohjaus PClta: USB-yhteytta koodataan paraikaa

Tehtavaa:

• Servojen ohjaus PWM:lla
• PClle mittarien kalibrointi/ohjelmointisofta
• PClle softa joka siirtaa tietoa simulaattorin ja ohjaamon valilla.

Tassa pari kuvaa raudan nykyvaiheista.

Mittarin pyoritys on suorastaan yksinkertaista. Tosin tama kuvassanakyva askelmoottori on senverran karkeasti askeltava, jotain 40 askelta per kierros, etta sen tilalle pitaa hankkia 200askelinen moottori.