Ik heb 2x TuxDroids wat ik bij interesse aan de RevSpace wil doneren. Wie weet een goede besteding? De HW is wat verouderd, rond 2008 kwam op de markt, maar zag ook schema’s uit 2006. Er is ook SW uit die tijd beschikbaar op Internet.
Zelf heb ik wat tijd gestoken in het zoeken naar mogelijkheden om het met een hedendaagse wireless connectie (bv. RPi Pico óf ESP32) te upgraden. Zou het interessant vinden om met een logic analyzer de instructies vanuit wireless daughter-board te ontcijferen, zodat het geheel met een Pico vervangen zou kunnen worden. Mocht je interesse hebben ik heb net project pagina aangemaakt.
Is hier toevallig iets van opgepakt door iemand?
Ik heb hier ook een stoffige tux liggen en ben wat aan het stoeien geweest.
Mijn idee was ofwel de wireless module te vervangen door een esp of nog beter een RPi4 of zo (al weet ik niet of dat gaat passen). Het main module blijft dan zoals het is maar de RPi kan dan prima de software draaien die normaal op de host PC draait.
Of vervangen van de hele electronica incl motor drivers door een RPi4 (of een Jetson Nano die hier nog stof ligt te happen).
Ik heb mijn Tux al eens opengemaakt en ik ben er ook ingeslaagd om de gpio’s aan te sturen vanuit een externe RPi. (stekker losgetrokken en daar een draadje aan gemaakt naar de pi; stekker loshalen viel trouwens nog niet mee).
Ik ben echter een software man (embedded linux). Ik heb geen idee wat voor HW ik nodig heb als driver voor de bestaande motoren, en ik heb ook geen idee hoe ik e.e.a er netjes ingepunnikt krijg.
Voor power wilde ik overigens een kleine power bank gebruiken.
Mocht er iemand zijn die hier al mee bezig is, dan wil ik graag in contact komen.
De TuxDroid staat nog vrijwel onaangeroerd op het plankje te wachten op iemand die voor hem wil zorgen. Een paar mensen hebben 'm even beetgepakt, maar knapten af op dat de soft touch coating helemaal plakkerig is geworden.
Ja dat plakkerige had ik geloof ik ook toen ik m na lange tijd weer uit de doos haalde. Heb ik toen wel schoon gekregen. Helaas woon ik niet in de buurt van Den Haag anders was ik graag eens langsgekomen.
@FransM: gezien dat best lang geen reactie kwam heb ik deze thread even uit het oog verloren. RPi4 is ietwat een overkill voor de Tux volgens mij Maar een RPi Pico óf ESP32 is een uitstekend boordje om de wireless module ermee te vervangen + past fysiek ook beter
Ben zelf minder in geïnteresseerd om de hele binnenkant te vervangen… heb twijfels over de build quality van een mogelijke vervanging en de hoeveelheid werk wat dat met zich meebrengt. De diepgaande details zijn een beetje vervaagd, maar de wirelless module communiceert via SPI protocol met de MCUs op de main board. Vraag is alleen wat precies de cmd’s zijn. Dit zou óf via sniffing van het SPI verkeer, óf vanaf de broncode van de FW achtergehaald kunnen worden.
Zelf ben geen C held, dus leek mij de 1e manier iets meer behapbaar. Maar zo te zien zou je meer aan de broncode hebben: GitHub - joelmatteotti/tuxfirmware: New firmware for TuxDroid (more infos here: http://forum.tuxdroid-community.org/viewtopic.php?id=197)
@gny De reden dat ik aan een RPi4 zat te denken was omdat het ding dan standalone kan opereren. Een nadeel van de tux vond ik altijd dat de applicatie op een PC draait en niet lokaal kan werken.
De cmd’s zijn wel uit te vogelen, daar zie ik niet zo tegenop. Ik ben zelf een ervaren C ontwikkelaar. Ik zie meer tegen het hw gebeuren op.
Ik heb overigens in de code ook een lijst van commando’s gevonden. Het lijkt erop dat alle comamndo’s 4 bytes zijn, eerste byte is command code, volgende drie zijn eventuele parameters (of leeg);
Deze repo is ook wel interessant
dit is een project om de internals door een pi te vervangen.
Ik meen dat ik zelfs een keer geprobeerd heb om in contact te komen met de auteur van die pagina maar zonder succes
(overigens heb ik ook een heleboel info gedownload van archive.org)
Mocht er interesse zijn dan kan ik alles wat ik heb wel een keer uploaden. Ik weet nog niet of ik dit in mijn uppie op ga pakken. Mocht er iemand een suggestie hebben voor een betaalbaar moderner alternetief voor de droid dan hoor ik dat ook graag.
Reden dat ik destijds de tux gekocht heb en niet bv een nabaztag is omdat de tux er zo kek uitzag. Er zijn nu natuurlijk allerlei robotics achtige dingen te koop, maar heb nog niet echt iets leuks gevonden.
Edit; ik heb voor mijn werk ooit met spot van boston dynamics gewerkt. Leuk ding, maar 75K ga ik thuis niet door de budget commissie krijgen
Aanvulling: via google kwam ik nog bij Eilik (https://energizelab.com)
Ziet er niet zo mooi uit als tuxdroid maar heeft wel wat meer functionaliteit.
Echter… geen open source of api en geen linux support
@gny De reden dat ik aan een RPi4 zat te denken was omdat het ding dan
standalone kan opereren. Een nadeel van de tux vond ik altijd dat de
applicatie op een PC draait en niet lokaal kan werken.
met een ESP32 of RPi Pico zijn er mogelijkheden om de Tux direct via WiFi óf
Bluetooth aanspreekbaar te maken. Je zult natuurlijk een of andere client
moeten gebruiken voor de aansturing van de Tux “acties”, maar dat kan variëren
van een browser, CLI oid. De client draait op PC óf mobiel. De ESP32 zelfs
audio mogelijkheden, maar dat is niet waar ik me in 1e instantie op richt.
Het energieverbruik zou ook een stuk minder zijn dan een RPi4.
Ik heb overigens in de code ook een lijst van commando’s gevonden. Het
lijkt erop dat alle comamndo’s 4 bytes zijn, eerste byte is command code,
volgende drie zijn eventuele parameters (of leeg);
We hebben het over de SPI commands van de de wireless module naar de mb,
correct? Dat is dan zeer interessant! Als je een keer tijd hebt lijkt me leuk
om deze door te lopen.
Ik heb even gekeken naar de repo; krijg de indruk dat de auteur er best werk
van heeft gemaakt. Zonder een plaatje van het eindresultaat vind het moeilijk
om voor me te zien wat hij/zij precies heeft gebouwd.
@gny Een ESP is wel zuiniger dus dat is wel een pre, de reden dat ik aan een RPi dacht was omdat die gemakkelijker autonomm kan werken (dus geen client nodig).
Voor de voeding zat ik te denken om er een power bankje in te knutselen.
Voorzover ik begreep zijn de codes van module naar main board hetzelfde als van client naar tux.
Dit zijn de cmd bytes:
dat komt uit de driver code.
En dit komt uit de firmware code:
Dat geeft nog wat meer info en zegt ook iets over de andere parameters.
Er worden steeds 4 byte berichten verzonden. De eerste is het cmd, de anderen zijn evt extra paramters zoals duration etc.
@gny Ik heb de keuze tussen esp32 vs rpi4 nog even laten bezinken.
om alleen het communicatie deel te vervangen is een esp een voor de hand liggende keuze.
In eerste instantie dacht ik de hele electronica te vervangen door een rpi en een motor shield, maar dat is wel een stuk ingrijpender.
Voordeel is wel dat er niet een bestaand protocol geimplementeerd hoeft te worden en dat de tux wat meer autonoom wordt.
Alleen de comm module vervangen is toch wat eenvoudiger.
Ik denk dat ik daar nog even wat verder induik.
Alleen de comm module vervangen is toch wat eenvoudiger. Ik denk dat ik
daar nog even wat verder induik.
tja… voordelen en nadelen natuurlijk. Qua HW aanpassing is het makkelijker,
maar de SW kost wat extra inspanning. Aan de andere kant dat ligt weer in je
straatje nietwaar
C is niet mijn sterkste punt maar als je een keer wil sparren, hoor ik het
wel.
Maar een RPi Pico óf ESP32 is een uitstekend boordje om de wireless module ermee te vervangen + past fysiek ook beter 
