node.js

"[..] et java-bibliotek (node.js) [..]"

node.js har intet med Java at gøre.

Hvor kommer robotten ind i billedet?

Der er intet interface på dette board, der egner sig til aktuatorer og sensorer endsige styring af servomotorer etc. Desuden vil det være temmelig tåbeligt at styre robotter, automation etc. med Linux/C direkte, da der så skal rettes i C-kode, hver gang robotten skal omprogrammeres. Board'et leveres ikke med en PLC fortolker. Desuden er Linux ikke noget RTOS.

Alternativ

Et billigere alternativ til BeagleBone er Raspberry Pi (se http://www.raspberrypi.org/)....g/). Model B har næsten samme specifikationer, men koster kun omkring 35$, når den kommer i salg sidst på året. BeagleBone har en lidt kraftigere ARM, men til gengæld har Raspberry Pi grafikprocessor og HDMI udgang.

..og hvis man vil introducere..

.. embedded programmering på et abstrakt niveau - så kan man købe en Netduino. Den er lige at gå til, deler mange features med Arduino så man let kan portere kode fra Arduino til Netduino.

Skal man nå et større publikum, så tror jeg man bliver nødt til at satse mere på .net. Det er ikke så lækkert, og langt fra så effektvit, men man kan komme ud over det støvede og nørdede Linux image :)

Re: node.js

"[..] et java-bibliotek (node.js) [..]"

node.js har intet med Java at gøre.

Måske har du lyst til at tjekke node.js's hjemmeside - eller wikipedias omtale og node.js ?

Re: node.js

node.js er skrevet i JavaScript, ikke Java.

JavaScript har *intet* med Java at gøre ud over at begge sprog indeholder ordet "java".

Re: Hvor kommer robotten ind i billedet?

Desuden er Linux ikke noget RTOS.

Med preempt-realtime patchet er det.

Re: node.js

"[..] et java-bibliotek (node.js) [..]"

node.js har intet med Java at gøre.

Måske har du lyst til at tjekke node.js's hjemmeside - eller wikipedias omtale og node.js ?

Nu glemmer vi lige Wikipedia og hopper direkte til nodejs.org, hvorpå der står, som overskrift:
"Evented I/O for V8 JavaScript."

Og så vil det klæde dig ikke at antage andre for værende idioter, især når din egen viden tilsyneladende er baseret på en hurtig google søgning, og forveksling af programmeringssprog.

node.js er skrevet i JavaScript, ikke Java.

JavaScript har *intet* med Java at gøre ud over at begge sprog indeholder ordet "java".

node.js er skrevet i C++, og er en server-side javascript runtime ;)
(men det vidste du jo godt)

Re: Hvor kommer robotten ind i billedet?

Hvis ellers boardet er forsynet med et antal gpio-ben, vil jeg sige at det er særdeles egnet til styring af hobby robotter. Linux giver let adgang til drivere til f.eks wifi via usb porten. Med en lille webserver er det let at web-enable den. Har du nogle io ben at trække i er det ikke raketvidenskab at styre et par servoer med pwm. Det med PLC fortolkeren kan jeg ikke helt formålet med... Ville nogen bruge det til en robot? Anyway, jeg ser det som en fordel at have en lille linux som base, det giver mulighed for at programmere i det sprog man måtte være mest hjemme i.

Re: Hvor kommer robotten ind i billedet?

Det med PLC fortolkeren kan jeg ikke helt formålet med... Ville nogen bruge det til en robot?

Prøv at se, hvordan en professionel industrirobot eller et procesanlæg programmeres. Det sker vha. et PLC lignende sprog og har ikke noget med C at gøre. Jeg har godt set en demonstration fra TI af små legetøjsrobotsystemer med individuelle ARM kort til de enkelte dele; men den slags løsninger ligger ærlig talt temmelig langt fra virkelighedens verden. Det samme gør PWM DC-servoer, som vist højest kan trække et par små rormoterer på et modelfly eller åbne et vindue i sneglefart. Det har ikke meget med robotteknologi at gøre, hvor tunge emner skal manipuleres med høj præcision langt hurtigere end Linux kan nå at skifte tasks.

Selvfølgelig kan man bygge et RTOS oven på Linux; men hvad skal man så med Linux kernen?

Re: Hvor kommer robotten ind i billedet?

@Carsten
Molnars RT patch er ikke ovenpå linux kernen, snarere tværtom. Google rtai osv og at der sælges kommercielle rt linuxer fra eks matworks.

Ikke alle prof industrisystemer programmeres i PLC lignende sprog.

Hvad du vil bruge en linux til i et rt system ?? Tja det som du nu vil bruge det til hvis du har behovene - så er den ikke længere.

Vi bruger feks linux ifm en dsp baseret sdr radiomodtager - virker faktisk godt :-)

Men helt enig i at de små brætter er hetl uden elektrisk beskyttelse af porte mm så de er uegnede til produktion, men til eksperimenter mm er de helt fine :-)

Re: Hvor kommer robotten ind i billedet?

Molnars RT patch er ikke ovenpå linux kernen, snarere tværtom. Google rtai osv og at der sælges kommercielle rt linuxer fra eks matworks.

Ikke alle prof industrisystemer programmeres i PLC lignende sprog.

Hvad du vil bruge en linux til i et rt system ?? Tja det som du nu vil bruge det til hvis du har behovene - så er den ikke længere.

Vi bruger feks linux ifm en dsp baseret sdr radiomodtager - virker faktisk godt :-)

Men helt enig i at de små brætter er hetl uden elektrisk beskyttelse af porte mm så de er uegnede til produktion, men til eksperimenter mm er de helt fine :-)

BeagleBone kortet har ikke den omtalte eller en tilsvarende real time patch. Derfor er det i grundversionen uegnet til real time brug, og 3.3 V portene er jo heller ikke specielt velegnet til direkte procesinterface. Hvis TI ville have lavet et kort egnet til robot- eller industristyring, skulle det i stedet have haft et feltbusinterface, et RTOS samt en PLC fortolker; men BeagleBone's hjemmeside fokuserer faktisk heller ikke på robotanvendelser.

Linux i alt. Ak ja. Et moderne TV med Linux (jeg har et) er mange gange længere tid om at starte op end et ældgammelt rør TV, som først skulle varmes på, og det tager over ét minut, før lydstyrkereguleringen bliver aktiv. Hvad i alverden skal man med Linux i et TV - eller i robotteknologi? Tænk hvis computersystemerne i en bil var lavet lige så tåbeligt.

Back on track.. please..

Lad os komme back on track - det er at skyde gråspurve med kanoner at diskueret hvilke styreformer eller sprog man benytter til kommercielle robotter. Dette board er ikke henvendt professionelle. Det er henvendt til dem som ønsker at smage lidt af microcontroller - det er til hobby projekter, proof-of-concept eller fast prototyping. Tag et kig på de projekter der er lavet på Arduino, så vil I nok have en bedre forståelse for hvad dette board ønsker at kunne (og specielt ikke kunne). Selv bruger jeg Arduino Uno og Duemilanove til fast prtotyping og til mindre projekter hvor jeg godt kan acceptere at løsnignen kører lidt langsommere end hvis jeg havde lavet det fra bunden i WinAVR eller Keil.


http://www.Arduino.cc

Re: Back on track.. please..

Jeg er skam på sporet. Titlen på bloggen omtaler en robotcomputer; men den betegnelse kan man vel næppe bruge om et kort, der i standardkonfigurationen ikke er i stand til at styre servomotorer i realtid. Det var bare det, jeg opponerede imod.

Hvorfor ikke bare kalde det for et ARM/Linux udviklingskort lige som alle andre tilsvarende kort?

Re: Back on track.. please..

Jeg er skam på sporet. Titlen på bloggen omtaler en robotcomputer; men den betegnelse kan man vel næppe bruge om et kort, der i standardkonfigurationen ikke er i stand til at styre servomotorer i realtid. Det var bare det, jeg opponerede imod.

Hvorfor ikke bare kalde det for et ARM/Linux udviklingskort lige som alle andre tilsvarende kort?

..og man kan ikke lave en robot uden at det skal være PLC styring? Der er lavet mange selvbalancerende robotter med Arduino..

Re: Back on track.. please..

... men den betegnelse kan man vel næppe bruge om et kort, der i standardkonfigurationen ikke er i stand til at styre servomotorer i realtid. Det var bare det, jeg opponerede imod.

For at eksperimentere med servoer og robotter hjemme på køkkenbordet med sønnike, er det vel ret beset heller ikke nødvendigt..

490 kroner...prisbillig computer enhed??

...
Hvis det skal bruges til embedded consum design (som f.eks. robotstøvsuger) så glem det...

Jeg ser igen og igen folk (chip producenter) der vil pushe Linux konsum embedded devices... det skal nok komme... men p.t. er det bare for dyrt design (og de fleste gange helt og adeles udnødvendigt overkill)...

I konsum design skal din produktionspris kunne holde til et markup på mindst x10 på prisen i forretningen...

(Jeg har kørt Linux siden de først slackware distributioner... så jeg er generelt MEGET pro-Linux)

Re: Hvor kommer robotten ind i billedet?

BeagleBone kortet har ikke den omtalte eller en tilsvarende real time patch. Derfor er det i grundversionen uegnet til real time brug, og 3.3 V portene er jo heller ikke specielt velegnet til direkte procesinterface. Hvis TI ville have lavet et kort egnet til robot- eller industristyring, skulle det i stedet have haft et feltbusinterface, et RTOS samt en PLC fortolker; men BeagleBone's hjemmeside fokuserer faktisk heller ikke på robotanvendelser.

Og hvis det skulle sendes ud i rummet har de også gjort en masse forkert, men hov, det var jo heller ikke det de skulle - hvor vil du hen med det der? Du kender tydeligvis intet til Arduino og hele det marked der omtales.

Linux i alt. Ak ja. Et moderne TV med Linux (jeg har et) er mange gange længere tid om at starte op end et ældgammelt rør TV, som først skulle varmes på, og det tager over ét minut, før lydstyrkereguleringen bliver aktiv. Hvad i alverden skal man med Linux i et TV - eller i robotteknologi? Tænk hvis computersystemerne i en bil var lavet lige så tåbeligt.

Så du vil i ramme alvor påstå at det er selve Linux' skyld, og ikke det faktum at dit tv tydeligvis er lavet af folk der enten har for travlt, eller ikke ved hvad de laver?!

Re: 490 kroner...prisbillig computer enhed??

...
Hvis det skal bruges til embedded consum design (som f.eks. robotstøvsuger) så glem det...

Jeg ser igen og igen folk (chip producenter) der vil pushe Linux konsum embedded devices... det skal nok komme... men p.t. er det bare for dyrt design (og de fleste gange helt og adeles udnødvendigt overkill)...

I konsum design skal din produktionspris kunne holde til et markup på mindst x10 på prisen i forretningen...

(Jeg har kørt Linux siden de først slackware distributioner... så jeg er generelt MEGET pro-Linux)

Nu er det også et udvklings board og ikke et final design, udover det så kører de fleste settop bokse, tv, pioneer tv, samt en del DVD afspillere og mange andre ting en eller anden form for linux.

så linux er mange steder i vores hverdag.

jeg glæder mig vildt til at kunne købe boardet, det skal nok blive til noget sjovt.

FPGA boads

Det har ikke meget med robotteknologi at gøre, hvor tunge emner skal manipuleres med høj præcision langt hurtigere end Linux kan nå at skifte tasks.

Det er muligt, at få et FPGA board, der kan bruges sammen med LabView og Lego Mindstorm. Det synes jeg umiddelbart virker som et godt "robotkit". Et "linux" kit, synes jeg er lidt kedeligt... Men det kan måske bruges til en brødrister.

Et FPGA board giver mulighed for digitalelektronik kan kodes ind i VHDL eller tegnes som diagram. Det er muligt, at indbygge mange CPU-kerner. Man kan synkronisere outputs fra en realtidsdel præcis, så signaler skifter, eksakt når programmet fortæller de skal skiftes, eller kan måle præcis når en indgang skifter til en realtidskerne, således det pågældende tidspunkt kan bruges i beregningerne, og eventuelt anvendes ved beregning af, hvornår en udgang præcis skal ændre sig. Og det kan styres, med tollerancer ned til få nanosekunder. Ofte er plads til adskillige små CPU kerner, der kan have små realtidsopgaver, og det er også muligt, at bruge en stor kerne, der kan programmeres f.eks. i C/C++, selvom C/C++ ikke lige er det sprog, jeg synes om, til pålideligt software. Dog, er det nok det højniveausprog(??), som er understøttet af de fleste systemer.

Linux vs. RTOS

>Nu er det også et udvklings board og ikke et final design, udover det
>så kører de fleste settop bokse, tv, pioneer tv, samt en del DVD
>afspillere og mange andre ting en eller anden form for linux.

List evt. din billigste BOM på et Linux system... (bare de store dyre komponenter)

Det du omtaler er high-end elektronik... du kan ikke sammenligne det med alm. konsum elektronik...

Jeg ved godt at hardware producenterne presser på... men linux kræver bare alt for meget i forhold til f.eks. FreeRTOS (eller lign.) ... og hvis du regner med at producere +1.000.000 enheder i en PLC... så vil hver krone sparet altså virkelig mærkes...

Ergo, så længe cost-effeciency forholdet er væsentligt meget højere ... så vil der nok gå laang tid inden de store producenter virkelig træder på Linux-speederen...

>så linux er mange steder i vores hverdag.

Ja da... og den vil være flere og flere steder..... min pointe er der går særdeles langt tid inden det er overalt...

Hvis du vælger Linux-hammeren... så skal du dæleme være særdeles klar over hvad din competitive edge er i dit produkt... for dine konkurrenter vil sikkert løbe dig over ende mht. pris...

Men det er da et fint board at lege med, og hvis dit produkt er low-volume (og dermed softwaren er den største del af produktets pris)... ja så er linux fint...

hvorfor er folk så sure ?

Det er da helt frivilligt om man vil bruge penge og energi å lidt beagle med linux, aduino med/uden freertos osv.

En std linux kan da sagtens køre realtid ! LIgesom en freertos maskine sagten ikke !!! kan køre realtid. Alt afhænger af de temporale constraints.
Har feks lavet realtids applikation med samplingsfrekvens på 0.05Hz og vanlige < 5% til jitter på gammeldags DOS PC uden problem. I den anden ende har v måske en avr med freertos der har mere end svært ved at håndtere en realtidsapplikation med samplingsfrekvens på 4 MHz.

Nu lige for at stresse realtidsbegreb. Realtid er ikke !! lig med høj samplingsfrekvens - det er at kunne reagere indenfor givne tidsgrænser, og hvis det er såkaldt hård realtid så falder hammeren hvis kravene ikke overholdes.

Jeg skal ha mig et stk beagle når det kommer - af ren interesse :-)

RE: hvorfor er folk så sure ?

Jeg taler kun costefficiency.. ikke temporale krav... men temporale krav som du foreslår sætter jo også bare cost-efficiency marginen opad...

Jeg tror at Richard vil blive citron-sur hvis jeg fortæller ham at FreeRTOS ikke kan overholde hårde tidskrav (for den sags skyld SafeRTOS)... han var forbi og spise "dansk" farsbrød med kartofler og brun sovs for en måned siden ...

RE: hvorfor er folk så sure ?

Har feks lavet realtids applikation med samplingsfrekvens på 0.05Hz og vanlige < 5% til jitter på gammeldags DOS PC uden problem.

For mange år siden, lavede jeg realtidsapplikationer i DOS, skrevet i turbo pascal. Det fungerede meget fint. Reelt, var dos'en dog koblet ud, og interrupt vektorerne blev sat om til mine egne. For at opnå mulighed for multitasking, brugte jeg mine egne multitasking rutiner.

Idag, foretrækker jeg at bruge en FPGA, eventuelt kombineret med en lille microcontroller kerne. Normalt anvender jeg ingen operativsystem, men sikrer at koden garanterer de ønskede svartider.

Realtidsprogrammering står normalt ikke inde for problemer som jitter. Det eneste som garanteres, er at softwaren svarer tilsrækkeligt hurtigt - eller hurtigere. Realtidssoftware garanterer svartiden, og at der ikke svares for sent. Den garanterer ikke normalt, at den ligger indenfor et bestemt vindue, eller ikke svares for tidligt.

Skal man sikre at et program svarer præcis til rette tidspunkt, så vil man normalt anvende noget hardware, der tidsstempler de indgange, hvis tidspunkt betyder noget i forhold til forsinkelserne, således at softwaren kan styre udgangene i forhold til tidspunktet. Og, man vil have noget hardware på udgangen, som skifter udgangen på det tidspunkt, som softwaren regner ud. Imellem indgangene og udgangene, har man så en realtids kerne - dennes opgave, er at garantere programmet er hurtig nok, i forhold til den forsinkelse der højst må være. Det betyder intet, at softwaren er hurtigere, da den udregner hvornår skiftet skal ske, og det skal bare modtages i tide af hardwaren - så sørger den for, at skifte præcis.

Man kan også lægge "hardwaren" ind i interrupts, der søger at tidsstemple, og skifte udgangen, på det rette tidspunkt, ved brug af timerinterrupts. Men, det er for så vidt udenfor realtidskernen. Realtids programmering, begyder ikke at der skiftes til tiden, kun at softwaren er hurtig nok, til at håndtere opgaven. Det er garanteret maksimal svartid, men ingen garanteret minimal svartid.

Man har derfor hellerikke indstruktioner som delays i realtids programmering, da de ikke giver nogen mening. Softwaren må gerne svare for hurtig. Hvis man vil lave en delay, så sker det ved, at man udregner tidspunktet som signalet skal skifte, og sender dette signal til udgangen. En udgang, der har et sekunds forsikelse i forhold til en indgang, laves ved at hardwaren tidsstempler indgangen når dataene påtrykkes, samt gemmer data indtil realtidskernen læser disse. Så udregner realtidskernen på data og på tidspunktet, og sætter det på den pågældende udgang. Dette skal ske, indenfor en afgrænset tid, da udgangen ellers ikke kan svare på det ønskede tidspunkt. Udgangen får såvel data der skal sendes ud, samt tidspunkt hvor data skal sendes ud, og sender dem ud på dette tidspunkt. Realtidskernen kan godt arbejde videre, efter den har sendt data ud til en udgang, og beregne andre udgange og tidspunkter.

Jitter giver derfor ikke direkte nogen mening, da fidusen ved realtids programmering, kun er at maksimum tider er overholdt. Resten sikres i hardware, eller ved der lægges en kerne udenom realtidsdelen, der kan modtage og tidsstemple inputs, samt sende outputs ud, på korrekt tidspunkt, med meget lidt jitter. Eventuelt er denne del lavet i hardware, for at næsten helt eliminiere jitter problemet.