Category Archives: Nezaradené

Embedded zariadenia a .NET

Pred nedávnom som objavil .NET Micro Framework (NET MF) a nedá mi sa nepodeliť o moje nadšenie. .NET Micro Framework je opensourcová platforma na vyvýjanie programov bežiacich na platformách s výrazne obmedzenými zdrojmi (minimum je tuším 128KB flash a 64KB RAM). NET MF sa líši od .NET Compact Edition hlavne tým, že CE potrebuje pre svoj beh hlavne operačný systém. NET MF je naproti tomu omnoho menší framework, ktorý sa ale sám stará napríklad aj o thread management.

Netduino PlusPre mňa, ako .NET programátora bolo vyskúšanie niektorého z dostupných zariadení neodolateľné, a hneď som si objednal Netduino, čo je tiež opensource platforma, snažiaca sa byť kompatibilná s veľmi obľúbeným Arduinom. Konkrétne ma zaujalo Netduino Plus, ktoré má okrem 48MHz ARM7 procesoru s 128KB flash pamatou a 60KB RAM priamo na sebe aj ethernet port a slot na SD kartu. Síce sa ku mne táto dostička dostala až po vianociach, ale aj tak som si našiel čas na to, sa s ňou hrať.

Doteraz som do programovania pre embedded systémy nevidel takmer vôbec. Tušil som, že developer potrebuje kompilovať programy pre daný procesor, že potrebuje mať programátor, ktorým skompilovaný program dostane do code pamäte, a že je celé programovanie dosť lowlevelové. Toto ale pre Netduino (a ani ostatné NET MF kompatibilné dev boardy) neplatí. Môj devboard má priamo na sebe USB konektor, ktorým sa napája do PC. Po nainštalovaní NET MF SDK a ešte ďaľšieho balíčka so SDK pre Netduino som pokračoval vytvorením nového projektu vo Visual Studiu, kde som priamo našiel template “Netduino plus project”, v novej záložke v project settings bolo už len treba nastaviť, ktoré pripojené NET MF zariadenie chcem používať na deploy a debug programu. Potom stačilo už len naprogramovať (v C#, nová verzia NETMF 4.2 už tuším vie aj VB.NET, ale ten jazyk som nikdy nemal rád) krátky program a zmačknúť F5 (ak nepoznáte Visual Studio, tak F5 je štandardná klávesa pre spustenie programu v debug móde) a VS program nasadilo na Netduino, restartovalo ho a spustilo debugovanie. Jednoduchšie si to už ani neviem predstaviť a fakt, že tento proces dokáže bez problémov zvládnuť aj úplný začiatočník si veľmi pochvaľujem. BTW okrem toho, že je to jednoduché, tak okrem Windows sú všetky použité programy aj zadarmo (Visual Studio 2010 Express – C#), ale vraj sa to dá rozbehať aj pod Monodevelopom pod linuxom.

Čo sa týka samotného programovania, tak NET MF je samozrejme (tak isto ako aj plný .NET) high level framework, takže napríklad nakonfigurovanie pinov ako digitálnych výstupov sa deje na pozadí vytvorenia objektu OutputPort (tak isto aj napríklad I2C, UART…) . Jasné je, že oproti full .NET obsahuje NET MF omnoho menej tried, ale nájdete tu základné triedy pre GPIO, UART, I2C, SPI, prácu so stringami, UTF8 encoding, komunikáciu po ethernete (IP), bitmapy, fonty a dokonca aj základy webservices a veľmi, veľmi oklieštené WPF.

Jediným limitom už potom ostáva Vaša fantázia a 60KB pamäte (ktoré Vám ostanú voľné pri používaní networkingu). Netduino ale nieje jediný hardware, na ktorom NET MF rozbehnete, teda sa tých 60kB neľakajte :-)

.NET Gadgeteer

Tu sa hodí spomenúť ďaľší pojem, a tým je .NET Gadgeteer, je to opensource toolkit na prototypovanie malých zariadení. Príkladom celého kitu môže byť FEZ Spider Starter Kit od GHI Electronics. Kit teda pozostáva z hlavnej dosky (FEZ Spider) a kopy Gadgeteer modulov. Každý modul sa do dosky (alebo iného modulu) zapája cez jeden alebo viac maličkých desaťpinových konektorov. V tomto konkrétnom kite nájdete napríklad ethernet modul, multicolor led modul, joystick modul, modul na SD kartu alebo dokonca grafický 3.5″ touch display a kameru.

FEZ SpiderFEZ Spider má na sebe 14 konektorov na gadgeteer moduly, ale nie všetky sú rovnaké. To, aké moduly môžete do daného konektoru zapojiť, určujú typy konektoru. Z každého 10pin konektoru sa používa prvý pin na napätie 3.3V, druhý pin na 5V a desiaty pin ako GND. Ostáva teda 7 pinov, ktorých možné využitie záleží na type socketu. Napríklad socket typ Y hovorí, že piny 3 až 9 sú GPIO piny a pin 3 podporuje interrupt. Typ U musí podporovať GPI s interruptom na pine 3, UART TX na pine 4, UART RX na pine 5 a GPIO na pine 6, kde piny 7, 8 a 9 niesú popísané. Každý socket môže mať viacero podporovaných gadgeteer typov, moduly väčšinou vyžadujú pripojenie k jednému konkrétnemu typu socketu.

.NET Gadgeteer designerSoftvérová výbava Gadgeteer je pre nepripraveného človeka veľkým (pozitívnym) prekvapením. .NET Gadgeteer program totiž môžete začať priamo preňho určeným designérom, spĺňajúcim rovnakú úlohu ako pri vývoji winforms aplikácie. V tomto designéri totiž pripájate moduly na mainboard, pri čom Vám nedovolí zapojiť moduly zle, v kóde aplikácie Vás potom už budú čakať nainicializované a vytvorené objekty reprezentujúce dané moduly.

Záverom mi nedá túto technológiu neodporučiť všetkým, ktorí sa chcú pohrať s embedded zariadeniami, ale s nimi nemajú zatiaľ žiadne skúsenosti alebo sa boja, že by ich to stálo veľa času. NET MF a aj .NET Gadgeteer Vám prichádzajú v ústrety a od vytvorenia vlastnej cez internet ovládanej pan + tilt kamery merajúcej aj teplotu a vlhkosť Vás nebude deliť viac ako pár dní veľmi vďačnej roboty.

Calculating hash while processing stream

Recently I needed to calculate hash of a unspecified Stream while I was processing its data. Along the way I discovered 3 additional methods to calculate hash – all suitable when you can’t rely on seeking in the stream.

The direct approach

Stream s = GetStreamFromSomewhere();
 
byte[] hash;
using (MD5 md5 = MD5.Create()) {
  hash = md5.ComputeHash(s);
}
s.Seek(0, SeekOrigin.Begin);
...

This is the direct approach to calculate hash from data in stream, but its setback is that after calculating the hash value the stream is read to the end. If the source stream was seekable (FileStream, MemoryStream…), you can just seek back and process the stream normally, but what if you can’t seek in the processing stream?

The block approach

You can calculate the hash on the go, using TransformBlock and TransformFinalBlock methods of MD5 class (or any other class implementing ICryptoTransform).

Stream s = GetStreamFromSomewhere();
 
using (MD5 md5 = MD5.Create())
{
  byte[] data = new byte[4096];
  int byteCount = 0;
  while ((byteCount = s.Read(data, 0, data.Length)) > 0) 
  {
    md5.TransformBlock(data, 0, byteCount, null, 0); // feed the data to MD5 algorithm
 
    // do something useful with the actual read data here
  }
  md5.TransformFinalBlock(data, 0, 0); // tell the algorithm that all data is read
 
  byte[] hash = md5.Hash;
}

This allows you to process the stream and calculate hash of the data at the same time, thus removing the need to read the entire stream twice, and removing the need to seek in the stream.

The nice approach – CryptoStream scenario #1

Stream s = GetStreamFromSomewhere();
 
using (MD5 md5 = MD5.Create())
{
  using (CryptoStream cs = new CryptoStream(s, md5, CryptoStreamMode.Read) 
  {
    int byteCount;
    byte[] data = new byte[4096];
    while ((byteCount = cs.Read(data, 0, data.Length)) > 0)
    {
      // do something useful with the actual read data here
    }
    byte[] hash = md5.Hash;
  }
}

As you can see, you can enclose the hash processing into CryptoStream, which is calculating the hash value during reading of the stream, which results in cleaner code.

Note – do not use CryptoStream.FlushFinalBlock() while using CryptoStreamMode.Read, because the CryptoStream itself can tell that the source stream reached its end and called this method already.

The nice approach – CryptoStream scenario #2

The scenario #1 is useful when you have a single source stream, but when you want to calculate hash value of output of your algorighm and do not have input in form of a stream, you can use CryptoStreamMode.Write.

Stream s = GetOutputStreamFromSomewhere();
 
using (MD5 md5 = MD5.Create())
{
  using (CryptoStream cs = new CryptoStream(s, md5, CryptoStreamMode.Write) 
  {
    while (! finished)
    {
      ...
      byte[] data = getNextDataChunk();
      ...
      cs.Write(data, 0, data.Length);
    }
    cs.FlushFinalBlock();
    byte[] hash = md5.Hash;
  }
}

Note – when using CryptoStreamMode.Write, you need to indicate to the hash algorithm that all data is written.

WCF Streaming

In my recent project I needed to use WCF streaming to transfer files between server and client, and I decided to share gained knowledge so you can use this techinque in your project more easily.

I will start with some more basic stuff, so feel free to skip some sections if you are sure you already know that topic.

1. If you plan to transmit more complex data, you need to control MessageContracts

WCF streaming supports only one stream in request or response message (that means: one in request; one in response; or one in request and one in response), but that is not all. In fact, message body should contain only the stream and nothing else. Thus you need to define message contracts so that all data other than the stream will be transmitted in message header.
This is quite easy even for programmer, who has only marginal overview of what the message contracts.

What this means for the host class definition:

Instead of specifying the transmitted content directly like this…

[ServiceContract(Namespace = "http://blog.monogram.sk/pokojny/example5/")]
public interface IMyAwesomeInterface {
  [OperationContract]
  bool PushFile(string filename, Stream data);
 
  [OperationContract]
  Stream PullFile(string filename);
}

… you should create classess representing transmitted messages …

[MessageContract]
public class PushFileRequest
{
  [MessageHeader]
  public string Filename
  { get; set; }
 
  [MessageBodyMember]
  public Stream Data
  { get; set; }
}
 
[MessageContract]
public class PushFileResponse
{
  [MessageHeader]
  public bool Result
  { get; set; }
}

… and modify your service interface (and its implementation(s)) to use these messages.

[ServiceContract(Namespace = "http://blog.monogram.sk/pokojny/example5/")]
public interface IMyAwesomeInterface {
  [OperationContract]
  PushFileResponse PushFile(PushFileRequest request);
 
  [OperationContract]
  PullFileResponse PullFile(PullFileRequest request);
}

2. Don’t even try wsHttpBinding

WS HTTP Binding does not support streaming, the whole message is buffered on the server, transfered to the client and buffered on the client. You should use basicHttpBinding or netTcpBinding instead.

3. Testing if the streaming really works

I had to be sure that I understand the differences in consuming and providing streamed vs buffered requests, so I wrote some test services and clients. Returning a MemoryStream or FileStream was not enough – I felt need to see that I had access to response before the whole stream was on client side. And this got me frustrated, because as I found out later (by trial and error), when using basicHttpStream, service proxy method won’t return control until:
1. the whole message including whole content of stream is on the client side
or 2. the receive buffer fills up

I implemented a simple stream that could be read once a second, returned current time and eventually stopped after 20 iterations. This simple test indicated, that something is wrong with the streaming, because the proxy method returned result only after the whole stream was read on the server. But after modifications (lowering the maxBufferSize, more data read from the time stream) I found out, that the message was really streaming.

When using netTcpBinding on the other hand, the proxy method returned response even before the receive buffer was full.

So when you are testing your application, I advise you to lower maxBufferSize and use netTcpBinding if possible, so you can get better feeling of what is actually happening.

4. How to implement processing of streamed messages

Client sending Stream – beware of disposing

This is actually straight forward, you just need to bear one thing in head – the actual usage of sent stream does not end the moment the control flow returned from the proxy class. Actually WCF could be reading the sent stream for quite a while after you got response from the server. And here comes the problem with disposing – you should dispose all used FileStreams, MemoryStreams etc, but you dont really know when. You should not use “using” blocks for this, as the stream could be disposed before it was read completely.

I came with a solution – to wrap actual stream into a object that will close and dispose the stream when the WCF finished reading it. This class must be derived from Stream class and should just forward method calls to the actual source stream. But when the source stream’s Read() method returned 0, the wrapper should close and dispose the source stream.

Service receiving Stream – not all Streams are meant to be closed

Beware of closing the WCF Stream client sent you – if you close it, you also close the WCF connection (at least when using netTcpBinding), which is definitely something you should let the WCF do.

Secondly, you can take advantage of the fact, that you can return result even before you read the whole sent stream – you can achieve this by reading the stream in another thread and return the response normally.

Service returning Stream – disposing #2

The same disposing problem as in “client sending stream” occurs also in this scenario, but it is more critical here. Let’s say that you want to stream contents of a file – you can do that just by returning opened FileStream (as WCF Sample from MS does :-| ), but the file remains opened even after it is read, which could be problem for a service, that should be running for long periods of time. (More possible scenarios could happen, not one of them is good.)

Thankfully, you can use the same trick as in “Client sending Stream” scenario – wrap the actual Stream and close it after it reads to the end.

Client receiving Stream – do not close that Stream

When client receives stream, the same problem as in “Service receiving Stream” scenario occurs. Just remember not to close the WCF Stream even after you processed/rewrote all its contents.

Final words

And that’s it, these are my basic hints for anyone trying to implement WCF Streaming. If you have additional questions or if you need example source code, just write so in the comments.

Collabtive – jednoduchý task management

Keď som sa začal účastniť tímových stretnutí vývojárov portálu blog.matfyz.sk, z hrôzou som zistil, že nepoužívajú žiaden project/task management software. Všetky tasky, bugy ale aj dokumenty sa distribuovali iba pomocou mailinglistu, čo bolo spočiatku dostatočné, ale s rozrastajúcim sa tímom stále viac chýbal celkový prehľad nad otvorenými bugmi, taskami a plánovanými taskami.

Preto som celý tím presviedčal, že potrebujeme nejaký project/task management software, jeho hľadanie prirodzene pridelili mne. Mal som niekoľko kritérií:

  1. Použitie zadarmo – pre takéto projekty sa ťažko zháňajú peniaze, a ak existuje alternatíva zadarmo, tak je lepšie použiť tú
  2. Majú webové rozhranie – áno, existujú aj také tooly, ktoré bežia ako desktopová aplikácia – tie sú ale väčšinou určené pre self-management
  3. Jednoducho používateľné a administrovateľné – toto v mojom prípade znamená okrem jednoduchého používania aj to, že by sw mal používať PHP, MySQL a bežať na Apache

Najlepší project/task management s akým som sa stretol ( JIRA ) teda vypadol z hry, keďže nieje použiteľný zadarmo ( teda, pre malé tímy do 10 ľudí za určitých podmienok áno, ale toto by bolo pre náš tím výrazné obmedzenie ), beží na Jave a je to dosť komplexný systém. Ako inak, veď je to enterprise systém.

Výsledkom môjho hľadania bolo viacero viac či menej vhodných riešení, ale jedno z nich ma okúzlilo postupne: jednoduchosťou inštalácie, príjemným používateľským rozhraním, prehľadnosťou a jednoduchosťou obsluhovania. Jedná sa o projekt Collabtive.

Hlavné features tejto aplikácie sú:

  • Project management
  • Task management
  • Timetracking

Vnútorná organizácia dát je jednoduchá a intuitívna:
Každý projekt má zadefinovaných niekoľko milestone-ov. Každý milestone má zadefinovaných niekoľko task-listov. Task list potom obsahuje konkrétne tasky. Tieto tasky sú klasicky pridelené používateľom/pracovníkom.

Okrem tejto hlavnej funkcionality potom ku každému projektu existuje webové úložisko dokumentov a správ posielaných medzi používateľmi.  Táto aplikácia dokonca poskytuje aj instant messageing systém pre prihlásených používateľov.

Prirodzene nechýbajú ani roly používateľov, teda do Vášho project managementu môžete napríklad pridať priamo Vašich klientov, ktorí budú vidieť progress v svojich projektoch, môžu zadávať tasky atď.

Všetku túto funkcionalitu systém zvláda pri zachovaní ľahkosti používania a prehľadnosti, za čo patrí vývojovému tímu môj obdiv. Samozrejme Collabtive nieje určený pre veľké korporácie, ale bez váhania ho odporúčam každému malému vývojovému tímu a freelancerom.

Blade 400 3D

E-Flite Blade 400 3D

E-Flite Blade 400 3D

Zastrájal som sa už skôr, ale čas som si našiel až teraz, mojou v poradí treťou RC helikoptérou je Blade 400 3D tiež od e-flite. Je to jednorotorová elektrická helikoptéra s premenlivým sklonom listov hlavného aj zadného rotora a ako napovedá názov, priemer rotorového disku je 80 cm.

Na rozdiel od mojich predchádzajúcich vrtuľníkov, tento stroj sa dá považovať za plne funkčný RC model helikoptéry, pretože princíp jeho fungovania a ovládania je rovnaký ako pri skutočných vrtuľníkoch – teda jeden motor poháňajúci aj hlavný aj zadný rotor a riadenie ťahu týchto rotorov pomocou zmeny uhlu nábehu listov rotorov.

Tento vrtuľník je určený na 3D akrobaciu a teda má oproti normálnej helikoptére väčšie možnosti manévrovania. Konkrétne:

  • má symetrické listy rotora – toto znamená, že je prierez listu symetrický podľa x-ovej osi a keď je uhol nábehu nastavený na 0°, listy negenerujú žiaden ťah. Symetrické listy sú menej účinné ako normálne asymetrické listy, ale majú aj niekoľko výhod: väčšia stabilita vo vetre, dokážu generovať rovnaký ťah oboma smermi
  • proporčne silnejší motor
  • listy hlavného (ale aj zadného) rotora sa môžu vychyľovať do oboch smerov rovnako – teda keď sú listy symetrické (čo sú), vrtuľník môže generovať ťah aj smerom “dole”, vďaka čomu môže prudko klesať, ale napríklad aj letieť dolu hlavou
  • rýchlejšie manévrovanie

Otázkou potom ostáva, prečo som si ako začiatočník vybral práve akrobatickú helikoptéru. No a odpoveď je jednoduchá, Blade 400 3D som si vybral preto, lebo:

  • distribuuje sa kompletne zložený a správne nastavený (určite by som si zpočiatku netrúfol zmontovať ho sám a hlavne doň vybrať vhodné servá, gyro a spol.)
  • je k nemu dodávané dosť dobré diaľkové ovládanie – Spektrum DX6i
  • sú naň celkovo dobré ohlasy

Simulátor

Po helikoptéru som si šiel do kamenného obchodu, predavač mi poradil, že by som sa ešte pred lietaním s touto helikoptérou mal naučiť ju ovládať na simulátore, čo mi znelo ako dobrý nápad a k môjmu nákupu som pridal ešte aj odporúčaný Phoenix RC simulátor, a nemôžem si ho vynachváliť, tento simulátor ma posunul o hodný kus vpred a to všetko bez nutnosti opravovať zničené modely :-)

Phoenix RC je počítačový simulátor leteckých modelov na diaľkové ovládanie. Ako vstupné zariadenie sa používa priamo Váš ovládač (čo je veľká výhoda, pretože aj v skutočnosti budete model riadiť tým istým ovládačom), prepojený s počítačom pomocou dodávaného kusu hardware-u. O kompatibilite ovládačov som toho moc nezisťoval, keďže ma predavač uistil, že s už mojim DX6i tento simulátor kompatibilný je.

Tento simulátor je veľmi realistický a popri možnostiach výberu z veľkého radu lietadiel a vrtuľníkov si môžete zalietať dokonca aj s vetroňmi, hydroplánmi, vírnikom či shiftRotorom (turbovrtuľové lietadlo s premenlivým smerom ťahu motorov). A medzi modelmi je aj môj Blade 400 3D ;-) . Navyše sú k tomuto simulátoru zadarmo dostupné aktualizácie s novými modelmi a letiskami.

Na výber máte aj z niekoľkých prednastavených nastavení počasia, ktoré si môžete upravovať. A program podporuje aj multiplayer – lietanie s ostatnými majiteľmi Phoenix RC cez internet, kde môžete sledovať, čo dokážu ostatní a učiť sa od nich.

Zozačiatku som rozbíjal nespočet modelov, kým som sa naučil RC helikoptéru dostatočne dobre ovládať. Dôležité nieje iba vedieť, ako helikoptéra reaguje (čo je veľmi náročné dobre simulovať), ale napríklad aj nestrácať orientáciu (teda v každom momente vedieť, v akom smere vrtulník letí, kam je nasmerovaný a čo treba spraviť, aby sa dostal do iného stavu).

Prvý let

Po nejakom čase som sa už odhodlal pre prvý “let”. K tejto príležitosti som si spravil tréningový kríž – 2 meter dlhé paličky, ktoré majú na koncoch napichnuté pingpongové loptičky, sú na seba kolmé a celý kríž je pripevnený k podvozku vrtuľníku. Tento kríž slúži na to, aby sa vrtuľník neprekotil na bok a tým chráni listy rotora, tiež ale pomáha pri tvrdších pristátiach a náraz mierne stlmí.

Vrcholom môjho letu bolo, že som sa zdvihol do výšky 5-10cm a takto nízko nad zemou som levitoval asi 30 sekúnd, ale to bolo presne to, čo som chcel docieliť. Vedel som, že časom sa mi podari s helikoptérou “pristáť” deštrukčným spôsobom, ale tento moment som chcel čo najviac oddialiť :-) .

Po zopár letoch som sa odhodlával na stále vyššie a vyššie lety. Samozrejme sa mi popri tom podarilo poničiť zopár sád listov zadného rotora a aj jednu sadu hlavného rotora, ale to boli očakávané straty.

Zatiaľ posledný let

Stav po poslednom lete

Stav po poslednom lete

Pri poslednom lete sa mi konečne podarilo helikoptéru poriadne rozbiť. Vtedy som sa vybral spolu s mojím strýkom na jednu lúku. Síce pofukoval vietor, ale to ma (bohužiaľ) neodradilo. Vzlietol som, asi 2 minúty som vzdoroval vetru v oblasti asi 10×10 metrov, potom som sa vybral spraviť kolečko a poryv vetra akurát v momente, keď som ho nepotreboval, zabezpečil, že sa môj model z asi 3metrovej výšky vydal priamo k zemi. A stav po zbežnom narovnávaní (aby sa aspoň zmestil do škatule) môžete vidieť na obrázku vpravo.

Opravy sú teraz v štádiu rozhodovania. Po zrátaní všetkých potrebných náhradných dielov som dospel k číslu 110€, čo by ani nebolo tak príliš veľa (ak vidíte ten obrázok), ale v jednom rakúskom internetovom obchode som našiel, že predávajú zmontovaný Blade 400 3D bez elektroniky za 116€ a ešte som sa nerozhodol, či budem opravovať starý alebo iba premontujem elektroniku do nového.

Do opravy som sa nepustil aj preto, lebo som v tom čase montoval môj najnovší vrtuľník, ale o tom až nabudúce.

Všade samé helikoptéry

Pôvodne som chcel iba napísať blogpost o tom, že sa zo mňa stal nerd do RC helikoptér a že už mám popri Blade CX3ke a Blade mSR už ďaľšie 2, ale to je iba časť informácií, ktoré by som chcel podať. Nakoniec píšem o tom, ako tieto hračky pre dospelých fungujú a prečo mi určite nestačia iba dve :-)

Najzákladnejšie delenie diaľkovo ovládaných helikoptér je založené na veľkosti, od nej sa odvíja veľa ďaľších možností a vlastností.

Najmenšie sú určite  hračky  typu Picoo Z. Jedná sa o veľmi malé (do 20cm) helikoptéry zväčša ovládané pomocou infračerveného diaľkového ovládača, ktorý má iba 2 kanály, jedným sa ovláda ťah hlavného motora a druhým rotor. Nedá veľa námahy zistiť, že na plnohodnotné ovládanie to je trochu málo, chýba možnosť ovládať pohyb vpred/vzad a do strán. Preto majú takéto helikoptéry ťažšiu prednú časť a konštantne idú vpred. Keďže majú iba do 10 gramov, nieje v nich žiadnej elektroniky naviac a ťah hlavného motora musíte vyrovnávať manuálnym ovládaním rotora.

Väčšími sú typicky koaxiálne ešte-stále-hračky ako napríklad Blade CX3. Tieto sa ovládajú už štvorkanálovým rádiovým diaľkovým ovládaním, dovoľujúcim meniť veľkosť vztlaku, rotáciu po zvislej osi a pohyb do všetkých štyroch strán. Slovo koaxiálne znamená, že majú dvojicu hlavných “vrtulí”, ktoré majú rovnakú os, sú umiestnené nad sebou a točia sa vzájomne opačne – vďaka tomu navzájom vyrovnávajú svoje odpory a helikoptéra nepotrebuje zadný rotor. Otáčanie do strán je zabezpečené rozdeľovaním rýchlosti otáčania jednotlivých vrtulí a pohyb dopredu/dozadu a do strán je získavaný náklonmi spodnej vrtule.
Tieto helikoptéry už väčšinou majú aj tzv gyro – zariadenie, ktoré zisťuje nežiaducu rotáciu celého vrtuľníka a samo ho vyrovnáva príkazmi zasielanými do ovládača zadného rotora resp v prípade koaxiálnych helikoptér do rozdeľovača energie dodávanej jednotlivým motorom.

Nasledujú jednorotorové mini-helikoptéry. Tieto majú rozmery listov hlavného rotora okolo 40cm a z toho vyplývajúce ďaľšie vlastnosti. V predchádzajúcich typoch helikoptér sa vztlak reguloval rýchlosťou otáčania vrtulí. Ale pri takýchto rozmeroch listov rotora treba už rátať aj s momentom zotrvačnosti listov – teda nieje možné dostatočne rýchlo zvýšiť vztlak zvýšením výkonu motora. Namiesto toho sa na regulovanie vztlaku používa iný trik, a tým je menenie uhlu nábehu listov rotora (v angličtine sa používa výraz collective pitch resp fixed pitch). Uhol nábehu sa dá zmeniť omnoho rýchlejšie ako rýchlosť otáčania hlavného rotora a tým pádom sa dá zabezpečiť dostatočne rýchle menenie vztlaku. Podobný problém nastáva aj na zadnom rotore, lepšie modely ovládajú ťah zadného rotora tiež menením sklonu jeho listov, zadný rotor je potom poháňaný hlavným motorom buď pomocou remeňa alebo hriadele.
Collective pitch sa dá použiť na ďaľší trik, jednoduchým zmenením uhlu nábehu do negatívnych hodnôt získame negatívny vztlak (nieje to korektný názov, ale isto viete, čo tým chcem povedať) a vrtuľník potom nieje ťahaný smerom hore ale tlačený smerom dolu. Toto sa dá využiť napríklad na letenie dolu hlavou alebo iné prvky extrémnej akrobacie.
Dôvodom, prečo dolu hlavou nevedia letieť normálne helikoptéry (okrem toho, že to je šialený nápad :-) ) je ten, že používajú iné listy rotora, ktoré majú prierez podobný prierezu krídla na lietadle a teda generujú stály vztlak aj keď majú uhol nábehu 0°, keď je teda uhol nábehu -10°, helikoptéra je tlačená dolu menšou silou, ako je normálne ťahaná hore pri +10°. Táto sila potom už nestačí na udržanie helikoptéry vo vzduchu. Aby sa ale takéto koniny dali robiť aspoň s helikoptérami na diaľkové ovládanie, používajú symetrické listy (teda ich prierez je symetrický a pri 0° uhle nábehu listov negenerujú žiaden vztlak). Normálne listy majú ale omnoho vyššiu efektivitu ako symetrické a to je dôvod, prečo sav praxi používajú.

No a ďaľšiu kategóriu tvoria helikoptéry s rozmermi listov nad 50cm, tieto majú zpravidla collective-pitch, zadný rotor poháňaný hlavným motorom a až donedávna boli poháňané výhradne spaľovacími alebo turbínovými motormi – v súčasnosti sa ale aj tu presadzujú elektricky poháňané helikoptéry. Pre väčšie rozmery sa ale od mini-helikoptér líšia aj letovými vlastnosťami. Sú stabilnejšie a menej citlivé na poryvy vetra. To je dôvodom, prečo sa v nich dá využívať aj Bellova hlava rotora (ok, o tomto som doteraz nehovoril, iba spomeniem, že mini-helikoptéry používajú bell-hiller mixing a menšie používajú hillerovu hlavu rotora, viac zaujímavejších info tu), ktorá poskytuje rýchlejšie odozvy ovládania.

Hádam som vás týmto krátkym článkom trochu uviedol do tejto zaujímavej témy a aspoň trochu obhájil moju novú závislosť na RC helikoptérach. :-)

Ďaľší prírastok do helikoptérového parku – Blade mSR

Behom posledných 3 týždňov som si doprial hneď 2 nové hračky. Dôvodom k tomu bola moja túha posunúť sa ďalej v oblasti RC helikoptér, začal som študovať ďaľšie zdroje o rozličných typoch helikoptér, o ich fungovaní, od pohonnej jednotky až po listy rotora. Uvedomil som si, že moja cesta musí viesť k jednorotorovým modelom. Hneď v zápätí som narazil na novo uvedenú vychvaľovanú mikrohelikoptéru E-flite mSR, ktorá je síce menšia od môjho Blade CX3, ale je rýchlejšia, agílnejšia a relatívne odolná.

Blade mSR

Po telefonáte do modelárstva som sa uistil, že tento zázrak majú a vybral sa ho kúpiť. Keďže som už mal ovládanie na CX3ku, chcel som si kúpiť verziu Bind-And-Fly (bez ovládača). Žiaľ, v takomto prevedení som mSR našiel iba v jednom českom e-shope, navyše iba o 15€ lacnejšiu (bez dopravy) od Ready-To-Fly verzie v kamennom modelárstve v Bratislave.

Blade mSR má vo výbave jednu veľmi dobrú vec – nabíjačku na jednočlánkové Li-Pol batérie, schopnú nabíjať 4 batérie naraz (v balení nájdete batérie 2), čo znamená, že dokážete zabiť lietaním úplne bez problémov skoro celý deň :-) , túto nabíjačku si nemôžem vynachváliť. Nabíjačka môže byť napájaná buď z adaptéra, alebo aj 4mi C batériami, takže nieste závislí na elektrickej sieti.

Ďaľšiu užitočnú vlastnosť nájdete na ovládači. Ako som spomenul vyššie, mSR je dosť agílna a rýchla. Ovládač (pôsobiaci veľmi jednoducho) má 2 módy, jeden s plným rozsahom ovládania a druhý menej citlivý – vhodný na prvé hodiny s mSR.

Za letu ma veľmi prekvapila stabilita, ak človek pustí ovládač, helikoptéra jednoducho zostane visieť vo vzduchu (samozrejme by v stabilnej polohe mala byť už pred pustením ovládania, inak bude pokračovať svojím smerom) – to sa mi s CX3kou tak ľahko nedarilo, aj keď by mala byť stabilnejšia, keďže je to koaxiálna helikoptéra. Po zopár tvrdších “pristátiach” (do steny, stropu a následne podlahy :-) ) som hneď zistil, že E-flite neklamal ani v ohľade odolnosti. Za to pravdepodobne môže nízka hmotnosť celej helikoptérky (aj s batériou iba 28g). Takže namiesto toho, aby som musel vymieňať dolámané listy rotora, vyrovnávať flybar a opraviť dosku cykliky, stačilo znova zasunúť povystrčenú batériu a mohol som pokúšať šťastie znova.

Doteraz sa mi podarilo pokaziť iba 2 veci – podvozok pri tvrdom pristátí a motor zadného rotora (nevedno kedy). Podvozok som zalepil kvapkou z gluegunu a celý chvost aj s motorom som vymenil za nový (26 sekundová operácia), a to už ten vrtuľník zažil kadejaké krkolomné pády.

S mSR som sa samozrejme prišiel pochváliť aj do práce, kde som inšpiroval hneď dvoch kolegov, ktorí si ešte ten deň zbehli kúpiť vlastné mSR. A aj keď mali s lietaním RC helikoptér prakticky nulové znalosti, základné ovládanie (na 90% úspešné vyhýbanie sa stenám) zvládli veľmi rýchlo a teraz sa vytešujú z novej zábavky. Ja som už vtedy pomýšľal nad ďaľším krokom v oblasti RC vrtuľníkov, a o tom napíšem v ďaľšom poste.

MONOGRAM Code 128 library

Pri jednom našom projekte som potreboval vedieť generovať čiarové kódy. Voľba formátu kódu padla na Code 128, pre jeho univerzálnosť a vysokú hustotu zapísanej informácie. Tento formát Vám umožňuje zapísať kompletne všetky znaky definované v ASCII, a to aj napriek tomu, že ASCII znakov je 128 a Code 128 má iba 106 znakov a to aj s jeho špeciálnymi znakmi.
Je to možné kvôli tomu, že existujú 3 jeho varianty:

  • 128A – znaky 0×00 – 0x5F
  • 128B – znaky 0×20 – 0x7F
  • 128C – iba číslice ( 0×30 – 0×39 ) – číslice sú ale kódované po dvojiciach, teda v dvojnásobnej hustote

Ako vidíte, znaky zapísateľné týmito variantami niesú disjunktné, napríklad číslice môžete zapísať všetkými troma variantami, veľké znaky abecedy variantou 128A aj 128B. Celý čiarový kód môže byť napísaný v jednej variante, ale môže používať aj viacero variánt na rôzne jeho časti. Medzi variantami sa dá prepínať špeciálnymi znakmi a dokonca medzi 128A a 128B dvoma spôsobmi. Čiarový kód je ľahké dekódovať, o čosi ťažšie ale je ho efektívne zapísať.

A práve absencia podpory varianty 128C v knižnici GenCode 128 ma donútila napísať vlastnú knižnicu schopnú využívať aj 128C variantu a inteligentne používajúcu všetky možnosti štandardu Code 128 za účelom čo najefektívnejšieho zápisu dát.

Knižnica MONOGRAM Code 128 library je šírená pod GNU LGPL, a zdrojové kódy ako aj skompilovanú assembly aj s testovacou aplikáciou môžete sťahovať odtiaľto.

Hľadáme programátorov

Hľadáme nových členov do našich developerských teamov. Viac info na stránkach monogramu.

Hľadáme C# programátorov

Podpora UniPlatby v MONOGRAM EPayment knižniciach

Po trochu voľnejšom víkende sa znova pohol vývoj EPayment knižníc a na svete je podpora UniPlatby (v PHP aj C# a aj v EPayment simulátori).

UniPlatba sa líši od ostatných platobných protokolov tým, že v payment requeste sa neuvádza návratová URL. Táto adresa je zadaná obchodníkom priamo banke a platí pre všetky jeho platby. Toto znamená miernu komplikáciu pri epayment simulátore, pretože ten nevie, kam má odpoveď zaslať. Vyriešené to je pridaním ďaľšieho fieldu pri vytváraní payment response-u, do ktorého môžete vpísať URL, na ktorú budete spolu s payment responsom presmerovaní.

Naopak milo ma prekvapilo, že v špecifikácii je priamo napísané, že túto službu môžete  používať aj s účtom v inej slovenskej banke. Posledným milým prekvapením bola rýchlosť, s akou nám z UniCredit Banky odpovedali na naše dotazy.

No a po zapracovaní malých zmien pri validácii odchádzajúcich správ vo všetkých implementáciách už releasneme nové verzie knižníc aj s podporou UniPlatby. Toto nastane pravdepodobne ešte dnes, takže sa môžete tešiť. Najrýchlejšie informácie nájdete na stránkach MONOGRAM EPayment knižníc.