Google brengt tweede developer preview voor Android Things uit

Google heeft de tweede developer preview uitgebracht van zijn Android Things-platform, dat als besturingssysteem dient voor iot-apparaten. In deze versie zit onder andere ondersteuning voor Google's TensorFlow. Dat is een softwarebibliotheek voor zelflerende systemen.

In de aankondiging van de preview zegt Google dat naast nieuwe functies ook bugfixes deel uitmaken van de nieuwe release. Een van de mogelijkheden van Android Things is het gebruik van TensorFlow. Hiervoor heeft het bedrijf een sample uitgebracht, aan de hand waarvan het mogelijk is om een afbeelding door het systeem te laten herkennen. Nadat de afbeelding is herkend, kan het systeem door middel van text-to-speech meedelen wat het herkende object is.

Een andere nieuwe functie is ondersteuning voor usb audio voor de Intel Edison en de Raspberry Pi 3. Ondersteuning voor bluetooth laat echter nog op zich wachten, aldus Google. Met de nieuwe release is Android Things nu ook te gebruiken op de Intel Joule en is er ondersteuning bijgekomen voor user drivers, die op een speciale pagina te vinden zijn.

Google introduceerde Android Things in december als een evolutie van het bestaande besturingssysteem Brillo. Het voordeel ten opzichte van die versie is dat ontwikkelaars gebruik kunnen maken van bekende Android-tools als Android Studio, het Google Cloud Platform, Google Play Services en de Android-sdk. Android Things is naast de eerdergenoemde apparaten ook te gebruiken op een NXP Pico.

Reacties (23)

[Boy]

Wat moet ik me voorstellen met USB audio? Ik heb al met preview 1 gespeeld. Je kan lekker snel aan de slag als Android developer. Audio afspelen ging prima toen.

Momenteel doe ik alles nog via Qt en C++ op de Pi...Maar het Android platform geeft veel toegevoegde waarde

[Verwijderd]

Volgens mij kan je tensorflow ook in C++ gebruiken.
Ik heb zelf het gevoel dat juist C++ weer in opkomst gaat komen in de hele IoT sector. Helemaal met QT dat de beste multiplatform ondersteuning bied. Daarnaast kun je met C++ tenminste deterministic programmeren en dus regeltechniek implementeren in kleine apparaten(met een RTOS) en direct linken aan andere apparaten die ook C++ hebben draaien of een pub/sub sessie met elkaar hebben en ga zo maar door.
C++ is dus zeker relevant en is ook aan het evolueren naar C++17 e.d.

Met al die fancy garbage collecting shit zijn zoveel dingen onvoorspelbaar. En we willen juist een voorspelbare code + voorspelbaar en zeker weten dat data ook aankomt over een netwerk, en zo niet daar realtime direct op inspringen.

[geoffrey.vl]

de rekenkracht van vele hedendaagse IoT devices (het type met een OS) laat gemakkelijk toe om programma's te ontwikkelen in programmeertalen zoals Java en C# (die draaien in een soort van eigen VM, en die een garbage collectie uitvoeren om out-of-scope objecten op te ruimen).
Het hangt er natuurlijk vanaf wat je zo allemaal op je IoT device wil draaien, daar zit een grote verscheidenheid in. IoT is bijvoorbeeld hoeft niet per definitie gebaseerd te zijn op een RTOS , het kan bijvoorbeeld ook een toestel zijn dat hele dagen slaapt en één keer per dag de temperatuur meet. Het is een grote verzamelingen van devices gemaakt met een divers arsenaal een hardware en met een minstens even divers software layers en tools.

Niet tegenstaande vind ik Qt best ook wel een interessant om een mooie cross-platform UI mee te bouwen.

[Verwijderd]

Maar uiteindelijk wil je naar zo goedkope mogelijk devices met zo min mogelijk rekenkracht om de kosten te drukken. Een Pi of Arduino board kan hardstikke veel en is relatief goedkoop, maar nog altijd te duur voor mass market IoT producten. Het is niet realistisch om zo'n ding in een koelkast van een paar honderd euro (winkelprijs) te bouwen. Dan moet het veel goedkoper worden.

[Mavamaarten]

Garbage collection maakt dingen onvoorspelbaar
Dat argument heb ik nog nooit gehoord. Het is ook gewoon compleet niet waar.

[Verwijderd]

Kan jij voorspellen wanneer de GC ingrijpt en wat hij precies doet? Vertel mij eens waarom in realtime deterministic doeleinden dan geen GC gebruikt word? Juist het antwoord is: Omdat de GC onvoorspelbaar is als je hem optimaal wilt gebruiken.

[Mavamaarten]

Nee, maar dat hoeft ook helemaal niet.
De garbage collector totaal geen enkele invloed op het resultaat van de uitvoer van je code. Op prestaties heeft deze een minimale invloed, maar zolang je je aan de OOP regeltjes houdt is dat geen probleem.

Ik begrijp best dat C(++) meer low level is en je daar geheugenmanagement op een absolute manier in de hand kan houden. Maar om daardoor meteen alle talen die aan GC doen af te schieten vind ik een beetje te extreem

[Verwijderd]

De GC heeft echt wel invloed op de timing van je output en dus wel invloed op de output. De inhoud van het resultaat kan wel hetzelfde zijn, maar niet wanneer deze inhoud gegenereerd zal worden. Dit is dus onvoorspelbaar gedrag.

[Mavamaarten]

Als de werking van de GC echt invloed heeft op de output en dit belangrijk is, dan heb je gewoon een programmeerfout gemaakt. Het is perfect mogelijk om code te schrijven die elke keer hetzelfde doet. Het enige dat mogelijk anders gaat zijn is wat er in het geheugen zit, maar zelfs dat gaat onder normale omstandigheden telkens hetzelfde zijn.

Als je denkt dat dit anders is ben je fout geïnformeerd.

[Verwijderd]

Vreemd dat er dan in kritieke software zoals in vliegtuigen, ziekenhuis apparatuur en defensie en ga zo maar door geen GC te vinden is.
Volgens jou zal dit zeker toeval zijn en ik verkeerd geïnformeerd zijn.

[Zezura]

Ikzelf heb de voorkeur voor C & C++.

Ik ben er ondertussen zo goed aangewend dat ik talen zoals Java en C# maar onhandig vind.
Met C++ weet je waar je aan toe bent.
C++ met Linux raspberry pi is ook niet heel moeilijk.

[Boy]

Ik vind de talen niet onhandig en tegenwoordig gebruik ik Kotlin voor dev op Android (Waar mogelijk).

Ben nu bezig met QML met C++ en dat gaat prima, maar het is niet zo dat C++ me meer bied hier dan de andere talen. Het is op dit moment het beste alternatief voor mij om voor de Pi te ontwikkelen en dit ook te kunnen draaien op de desktop. En erg leuk om te doen!

[JohnD1]

Op zich maakt het niet uit welke taal je iets schrijft C, C++, Java, perl, php...., syntax is ongeveer allemaal hetzelfde..
Het zijn meestal de beschikbare libraries/classes die het complex/makkelijk maken.

Zelf geef ik de voorkeur aan C, maar dat houd soms in dat ik bepaalde functionaliteit zelf moet maken/overnemen. Bij Java krijg ik meestal het gevoel dat er een enorme bulk aan afhankelijkheden van classes/libraries tevoorschijn komt.

[Zezura]

Niet allen de syntax, of code in het algemeen, maar tools maken ook verschil.

[OverSoft]

Luidsprekers en koptelefoons die een ingebakken USB geluidskaart hebben en dus alleen aansluiten via een USB plug (geen jack plug).

[MrMonkE]

Zoals bijvoorbeeld koptelefoon versterkers?

[rolandlub]

Ik denk zoals mijn (originele) Corsair H1500.

[Commander69]

Leuke ontwikkeling, maar hebben we al niet genoeg standaarden voor home autoation en iot ?

[Reactie gewijzigd door Commander69 op 22 juli 2024 21:54]

[gabba25]

Ik denk dat Google deze markt niet wil missen, aangezien er voorspeld is dat de iot markt enorm gaat groeien. Dat gezegd hebbende, er zijn ook weinig markten waar Google niet in meespeelt

[SampleUser]

Google heeft de macht om zoiets te kunnen doen. Net zoals met Google Transit: of je pusht de data naar Google in eigen format (GTFS), of je mist een hele grote userbase.

[Verwijderd]

Er zijn verschillende usecases. Er zijn standaarden die zijn compleet en kunnen alles, maar die zijn dan weer te complex om even te implementeren. Zo krijg je een wildgroei aan standaarden.

[Verwijderd]

Als de API goed zijn beschreven hoeft het niet complex te zijn. Een paar API's zul je altijd nodig hebben, en andere zijn weer wat exclusiever. DUs voor eenvoudige IoT toepassingen zullen de basic API's voldoende kunnen zijn en kan je gewoon de standaard gebruiken zonder alle moeilijke toeters en bellen te gebruiken.

[Verwijderd]

Natuurlijk, ik begrijp je. Maar met de implementatie bedoelde ik niet de api. De implementatie kan namelijk zeer complex zijn en de api simpel. Dan is het nog lastig om die "makkelijke api" te implementeren op verschillende platformen.