Vinster:
- Förmåga att sätta upp och lösa framåt/invers kinematik och banaplaneringsproblem med hjälp av AI
- Förmåga att skapa säker omloppsbana genom att ge robotens ledgränser, hastighets- och accelerationsbegränsningar som sammanhang till prompten
- Förmåga att numeriskt och fysiskt verifiera kinematisk och bana utdata som produceras av AI
Att föra gripdonet i änden av en robotarm till en viss punkt i rymden, i en viss orientering; Det låter enkelt, men det finns kinematiska ekvationer, ledgränser, singulariteter och banplanering bakom. Här använder mekatronikingenjören trigonometri, linjär algebra och kontrollteori tillsammans. Artificiell intelligens är ett kraftfullt hjälpmedel i denna process: den kan upprätta framåtkinematikekvationer, föreslå lösningsmetoder för invers kinematik, parametrisera en bana enligt hastighets-/accelerationsbegränsningar. Robotteknik är dock ett av de områden inom mekatronik med högst fysisk risk; Om en vinkelsekvens som genereras av AI skickas till roboten utan verifiering, kan armen träffa sig själv, omgivningen eller operatören. I den här enheten kommer vi att se hur man ställer in och verifierar kinematik och banaplanering med AI.
Framåt och omvänd kinematik
Forward kinematics (FK): Hitta ändeffektorns position och orientering om ledvinklarna är kända. Det finns bara en lösning, den är direkt.
Invers kinematik (IK): Om den önskade positionen för slutfunktionen är känd, hitta ledvinklarna som ger detta. Den har vanligtvis mer än en lösning (som armbåge upp/ner), ibland har den inga lösningar (otillgänglig punkt), ibland har den oändliga lösningar (singularitet).
koncept
ingång
utgång
Antal lösningar
Framåt kinematik
ledvinklar
Extrem position/orientering
singel
Invers kinematik
Extrem position/orientering
ledvinklar
Flera/ingen/oändlig
För en tvåledad plan arm kan invers kinematik ställas in i AI och verifieras manuellt enligt följande:
importera numpy som npdef inverse_kinematik_2r(x, y, L1, L2): """IK för 2-ledad plan arm. Returnerar vinklar i radianer (lösning med armbåge ner).""" r2 = x**2 + y**2 # Tillgänglighetskontroll: är punkten i arbetsytan? om np.sqrt(r2) > (L1 + L2) eller np.sqrt(r2) < abs(L1 - L2): höj ValueError("Punkten är utanför det tillgängliga arbetsutrymmet") cos_t2 = (r2 - L1**2 - L2**2) / (2 * L1 * L2) cos_0.klipp 1.0) # numericalsecurity t2 = np.arccos(cos_t2) # armbåge ner t1 = np.arctan2(y, x) - np.arctan2(L2*np.sin(t2), L1 + L2*np.cos(t2)) retur np.degrees(id.degrees:degrees(np.degrees)# L1=L2=1, mål (1,1) -> förväntat t2=90 graderstryck(inverse_kinematik_2r(1.0, 1.0, 1.0, 1.0)) # ~ (0.0, 90.0)
De kritiska linjerna här är där AI ofta hoppar över: nåbarhetskontroll (är punkten i arbetsytan) och `np.clip` (förhindrar arccos-ingång från att gå över ±1 på grund av avrundningsfel). Utan dessa två skydd kommer koden att producera NaN eller krascha vid en ogiltig punkt.
Tips: När du frågar efter IK-upplösning, berätta tydligt för AI:en att "lägga till tillgänglighetskontroll och begränsa arccos-ingång till klipp". Dessa två rader förhindrar de tysta felen som orsakar mest huvudvärk i fältet.
Gemensamma gränser, singularitet och flera lösningar
Varje led i en riktig robot har ett vinkelområde (t.ex. -170° till +170°), en hastighetsgräns och en accelerationsgräns. Även om IK ger en matematiskt giltig vinkel kan den inte användas om den vinkeln ligger utanför ledens fysiska räckvidd. Dessutom faller roboten i singularitet i vissa konfigurationer: två axlar är inriktade, en frihetsgrad går förlorad och ledhastigheter försöker gå till oändlighet för en liten spetsrörelse.
Det är därför det inte räcker med enbart HR-lösning; Varje lösning måste passera ett acceptansfilter:
def solution_gecerli_mi(acilar_deg, limits_deg): """smärtor: [t1,t2,...], gränser: [(min,max),...]""" för smärta, (amin, amax) i zip(acilar_deg, limits_deg): om inte (amin <= smärta <= amax): returnera grader False, f:}Jofintgräns: överskridit ({amine},{amax}) except" return True, "OK"limits = [(-170, 170), (-120, 120)]print(cozum_valid_mi([0.0, 90.0], limits)) # (True, 'OK')print(cozum_valid_mi([0.0,F limit], #Jointals limit], överskrids...')
AI kan ge den "matematiska" lösningen av IK; men gemensamma gränser och undvikande av singularitet är specifika för ditt system och måste ges som sammanhang till prompten.
Orbit planering
Att få roboten från punkt A till punkt B handlar inte om att dra en rät linje mellan två vinklar. Plötslig hastighetsändring skapar mekaniska stötar och vibrationer. Istället används mjuka profiler: trapetsformad hastighetsprofil (konstant acceleration–konstant hastighet–konstant retardation) eller S-kurva (jämnare, där accelerationen också är begränsad). När du får AI att generera en bana måste du ange målet, varaktigheten och begränsningarna.
importera numpy som npdef trapez_yorunge(q0, q1, v_max, a_max, dt=0.01): """Trapetsformad hastighetsprofil för en enstaka led. Positionsmatrisen returneras.""" distance = abs(q1 - q0) riktning = np.sign(q1 - /speed_max. t_max_0) t_max_0) * a_max * t_speed**2 om 2 * distance_speed > distans: # triangulär profil (v_max kan inte nås) t_speed = np.sqrt(distance / a_max) t_constant = 0.0 v_peak = a_max * t_speed else: t_constant =peak = * v_max - t_max T = (distans v_max - max)2 2 * t_accelerate + t_constant t = np.arange(0, T, dt) # ... positionsberäkning för varje t (baserat på accelerations-/konstant-/retardationsfaser) return t, T, v_peak, varaktighet, vz = trapetsoidal_trajectory(0.0, 0,=60, v_max. a_max=120.0)print(f"Total varaktighet: {duration:.3f} s, topphastighet: {vz:.1f} grader/s")
Den logiska kontrollen här är denna: om avståndet är kort kommer motorn aldrig att nå v_max och profilen kommer att vända från trapetsformad till triangulär. Om AI:n missar detta tillstånd kommer fel varaktighet att beräknas för korta rörelser. Du kan verifiera detta genom att testa koden med ett känt värde (till exempel ett mycket kort avstånd).
Svag prompt / Stark prompt
SVAG:"Skriv en bana som tar robotarmen från A till B."(Ingen begränsning: hastighetsbegränsning? acceleration? ledavstånd? Blind utdata.)STARK:"Generera en punkt-till-punkt-bana i ledutrymmet för en 6-axlig robot. Hastighetsgränsen för varje led är 90 grader/s, accelerationsgränsen är given i fältet 180 graders vinkel. ^2 Hastighetsprofilen, om avståndet är kort, faller in i en triangulär profil. Utdata från varje led är också att skriva en verifieringsfunktion som kontrollerar att den inte överskrider gränserna för leden: {{tabell}}.
Verifiering: Från simulering till robot
Banan som genereras av AI:n verifieras i denna ordning innan du går till roboten:
- Numeriskt: Är ledvinkeln, hastigheten och accelerationen för varje steg inom gränserna?
- Kollision: Längs banan, kolliderar armen med sig själv eller omgivningen (visualisera/simulerar om möjligt)?
- Singularitet: Passerar omloppsbanan genom ett singularitetsområde (närmar sig den jakobianska determinanten noll)?
- Långsamt hårdvarutest: Kör roboten med låg hastighet (t.ex. 10%) och övervaka den visuellt.
- Gradvis hastighetsökning: När allt är verifierat ökar hastigheten steg för steg till det nominella värdet.
Varning: När du startar en robot med en ny bana för första gången ska hastighetsöverstyrningen alltid vara låg och nödstoppet ska vara tillgängligt. Även om AI-utgången är "matematiskt korrekt", kommer en förskjutning, omvänd axel eller kabelhake i den fysiska installationen endast att avslöjas med långsam testning.
Minifodral
Automationsingenjör Ece ber AI:n om en bankod i gemensamt utrymme för en plock-and-place-applikation. AI:n producerar en trapetsformad profil, men när Ece testar ett kortdistansdrag ser hon att tiden är negativ: koden hanterade inte det triangulära profilfallet där v_max inte kan nås. Ece korrigerar detta genom att säga till prompten "om avståndet är kort, fall in i den triangulära profilen". Den kör sedan ledvinklarna som ges av AI:n genom sin valideringsfunktion mot sin egen gränstabell och finner att led 5 ville ha +125° vid en punkt, medan gränsen var +120°. Han planerar om banan och övervakar den, denna gång kör han roboten med 10 % hastighet. I första omgången ser han att griparen kommer för nära bordet och korrigerar Z-offset. AI:n returnerade en fungerande kontur på några minuter; men tre separata valideringar (triangulär profil, ledgräns, långsamt test) fångade tre separata verkliga problem.
Vanliga misstag
- Använder IK-lösningen utan gemensamma begränsningar och tillgänglighetskontroll.
- Klipper inte arccos/arcsin-poster utan producerar NaN vid avrundningsfel.
- Begär omloppsbana utan att begränsa hastighet/acceleration och skapa mekaniska stötar.
- Att ignorera singularitetszoner och låta foghastigheterna skjuta i höjden.
- Hoppa över trapetsformad-triangulär profilövergång på kort avstånd och beräkna fel tid.
- Genomför det första omloppstestet i full fart och utan nödstopp.
Sammanfattningsvis
- Forward kinematics har en enda lösning; invers kinematik kan producera flera, obefintliga eller oändliga lösningar.
- IK-lösningar är nödvändigtvis filtrerade i termer av gemensamma gränser, tillgänglighet och singularitet.
- Banplanering; Den använder mjuka, gränskompatibla profiler som trapetsformad eller S-kurva.
- På kort avstånd ändras profilen från trapetsformad till triangulär; detta ska hanteras i koden.
- AI påskyndar matematiken; Gränserna och det fysiska installationssammanhanget bör anges i prompten.
- Den nya banan körs alltid för första gången med ett lågt hastighetsförhållande och tillgängligt nödstopp.
Applikationsuppgift
Välj en två- eller treledad armmodell (med verkliga eller imaginära länklängder och ledgränser). Låt AI generera en invers kinematikfunktion och en banaplanerare med detta sammanhang. Sedan: (1) verifiera IK-utgången manuellt med ett känt mål (lägger du tillbaka vinklarna och återgår till samma punkt som FK), (2) testar att koden fångar dem genom att ge minst en otillgänglig punkt och en gemensam gräns som överskrider målet, (3) kontrollera att omloppstiden på kort avstånd visar sig vara rimlig. Skriv ner hur många valideringsproblem du hittade i den första versionen av koden och vilket lager som fångade var och en.