Gevinster:
- Evne til at opsætte og løse fremad/invers kinematik og baneplanlægningsproblemer ved hjælp af AI
- Evne til at producere sikker kredsløb ved at give robotledgrænser, hastigheds- og accelerationsbegrænsninger som kontekst til prompten
- Evne til numerisk og fysisk at verificere kinematisk og baneoutput produceret af AI
At bringe griberen for enden af en robotarm til et bestemt punkt i rummet, i en bestemt orientering; Det lyder simpelt, men der er kinematiske ligninger, ledgrænser, singulariteter og baneplanlægning bag. Her bruger mekatronikingeniøren trigonometri, lineær algebra og kontrolteori sammen. Kunstig intelligens er en stærk hjælp i denne proces: den kan etablere fremadgående kinematik-ligninger, foreslå løsningstilgange til invers kinematik, parametrisere en bane i henhold til hastigheds-/accelerationsbegrænsninger. Robotteknologi er dog et af de områder inden for mekatronik med den højeste fysiske risiko; Hvis en vinkelsekvens genereret af AI sendes til robotten uden verifikation, kan armen ramme sig selv, miljøet eller operatøren. I denne enhed vil vi se, hvordan man opsætter og verificerer kinematik og baneplanlægning med AI.
Fremadrettet og omvendt kinematik
Forward kinematics (FK): Finding af sluteffektorens position og orientering, hvis ledvinklerne er kendte. Der er kun én løsning, den er direkte.
Invers kinematik (IK): Hvis den ønskede position for slutfunktionen er kendt, skal du finde de ledvinkler, der vil give dette. Det har normalt mere end én løsning (som albue op/ned), nogle gange har det ingen løsninger (uopnåeligt punkt), nogle gange har det uendelige løsninger (singularitet).
koncept
input
output
Antal løsninger
Fremadrettet kinematik
ledvinkler
Ekstrem position/orientering
single
Invers kinematik
Ekstrem position/orientering
ledvinkler
Multiple/ingen/uendelig
For en to-leddet plan arm kan omvendt kinematik konfigureres i AI og verificeres manuelt som følger:
import numpy som npdef inverse_kinematik_2r(x, y, L1, L2): """IK for 2-leddet plan arm. Returnerer vinkler i radianer (albue-ned løsning).""" r2 = x**2 + y**2 # Tilgængelighedstjek: er punktet i arbejdsområdet? hvis np.sqrt(r2) > (L1 + L2) eller np.sqrt(r2) < abs(L1 - L2): hæv ValueError("Punkt er uden for det tilgængelige arbejdsområde") cos_t2 = (r2 - L1**2 - L2**2) / (2 * L1 * L2) cos_0.klip,( = 1s_0, clip) 1.0) # numericalsecurity t2 = np.arccos(cos_t2) # albue ned t1 = np.arctan2(y, x) - np.arctan2(L2*np.sin(t2), L1 + L2*np.cos(t2)) return np.degrees(np.degrees(np.degrees)# L1=L2=1, mål (1,1) -> forventet t2=90 gradersprint(inverse_kinematik_2r(1.0, 1.0, 1.0, 1.0)) # ~ (0.0, 90.0)
De kritiske linjer her er, hvor AI'en ofte springer over: tilgængelighedskontrol (er punktet i arbejdsområdet) og 'np.clip' (forhindrer arccos-input i at gå ud over ±1 på grund af afrundingsfejl). Uden disse to beskyttelser vil koden producere NaN eller gå ned på et ugyldigt punkt.
Tip: Når du beder om IK-opløsning, skal du tydeligt fortælle AI om at "tilføje tilgængelighedskontrol og begrænse arccos-input til klip". Disse to linjer forhindrer de tavse fejl, der giver mest hovedpine i marken.
Fællesgrænser, singularitet og flere løsninger
Hvert led i en rigtig robot har et vinkelområde (f.eks. -170° til +170°), en hastighedsgrænse og en accelerationsgrænse. Selvom IK giver en matematisk gyldig vinkel, kan den ikke bruges, hvis denne vinkel er uden for leddets fysiske rækkevidde. Derudover falder robotten i singularitet i nogle konfigurationer: to akser er justeret, en grad af frihed går tabt, og ledhastigheder forsøger at gå til det uendelige for en lille spidsbevægelse.
Derfor er HR-løsning alene ikke nok; Hver løsning skal bestå et acceptabilitetsfilter:
def solution_gecerli_mi(acilar_deg, limits_deg): """smerter: [t1,t2,...], grænser: [(min,max),...]""" for smerte, (amin, amax) i zip(acilar_deg, limits_deg): hvis ikke (amin <= smerte <= amax): returner deg False, f:}Jofint grænse: overskredet ({amine},{amax}) undtagen" returnerer Sand, "OK"grænser = [(-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], #Jointals limit], overskredet...')
AI kan give den "matematiske" løsning af IK; men fælles grænser og undgåelse af singularitet er specifikke for dit system og skal gives som kontekst til prompten.
Baneplanlægning
At få robotten fra punkt A til punkt B handler ikke om at tegne en ret linje mellem to vinkler. Pludselig hastighedsændring skaber mekaniske stød og vibrationer. I stedet bruges bløde profiler: trapezformet hastighedsprofil (konstant acceleration–konstant hastighed–konstant deceleration) eller S-kurve (glattere, hvor accelerationen også er begrænset). Når du får AI til at generere en bane, skal du angive målet, varigheden og begrænsningerne.
importer numpy som npdef trapez_yorunge(q0, q1, v_max, a_max, dt=0.01): """Trapezformet hastighedsprofil for et enkelt led. Positionsarrayet returneres.""" distance = abs(q1 - q0) retning = np.sign(q1 - /speed_max =_speed_max. t_speed_max. * a_max * t_speed**2 if 2 * distance_speed > distance: # trekantet profil (v_max kan ikke 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 - peak = * v_max - max. 2 * t_accelerate + t_constant t = np.arange(0, T, dt) # ... positionsberegning for hver t (baseret på accelerations-/konstant-/decelerationsfaser) returnerer t, T, v_peak, varighed, vz = trapezoidal_trajectory(0,0, v_max. a_max=120.0)print(f"Samlet varighed: {varighed:.3f} s, spidshastighed: {vz:.1f} grader/s")
Det logiske tjek her er dette: Hvis afstanden er kort, når motoren aldrig v_max, og profilen vil vende fra trapezformet til trekantet. Hvis AI'en savner denne betingelse, vil den forkerte varighed blive beregnet for korte bevægelser. Du kan verificere dette ved at teste koden med en kendt værdi (for eksempel en meget kort afstand).
Svag prompt / stærk prompt
SVAG:"Skriv en bane, der tager robotarmen fra A til B."(Ingen begrænsning: hastighedsbegrænsning? acceleration? ledafstand? Blind output.)STÆRK:"Generer en punkt-til-punkt bane i ledrummet for en 6-akset robot. Hastighedsgrænsen for hvert led er 90 grader/s, accelerationsgrænsen er givet 180 graders intervaller, fælden er angivet i vinkelområdet.^2. hastighedsprofil, hvis afstanden er kort, falder ind i en trekantet profil.
Verifikation: Fra simulering til robot
Den bane, der genereres af AI, verificeres i denne rækkefølge, før den går til robotten:
- Numerisk: Er ledvinklen, hastigheden og accelerationen for hvert trin inden for grænserne?
- Kollision: Kolliderer armen langs banen med sig selv eller omgivelserne (visualisere/simulere hvis muligt)?
- Singularitet: Passerer kredsløbet gennem et singularitetsområde (nærmer den jakobiske determinant sig nul)?
- Langsom hardwaretest: Betjen robotten ved lav hastighed (f.eks. 10%) og overvåg den visuelt.
- Gradvis hastighedsforøgelse: Når alt er verificeret, øges hastigheden trin for trin til den nominelle værdi.
Forsigtig: Når du starter en robot med en ny bane for første gang, skal hastighedstilsidesættelsen altid være lav, og nødstoppet skal være tilgængeligt. Selvom AI-outputtet er "matematisk korrekt", vil en forskydning, omvendt akse eller kabelhak i den fysiske opsætning kun blive afsløret ved langsom test.
Mini etui
Automationsingeniør Ece beder AI'en om en banekode i fællesrum til en pick-and-place-applikation. AI producerer en trapezformet profil, men da Ece tester et kortdistancetræk, ser hun, at tiden er negativ: koden håndterede ikke det trekantede profiltilfælde, hvor v_max ikke kan nås. Ece retter dette ved at fortælle prompten "hvis afstanden er kort, fald ind i den trekantede profil". Den kører derefter ledvinklerne givet af AI'en gennem sin valideringsfunktion mod sin egen grænsetabel og finder ud af, at led 5 ønskede +125° på et punkt, hvorimod grænsen var +120°. Han omplanlægger banen og overvåger den, denne gang kører robotten med 10 % hastighed. I første runde ser han, at griberen kommer for tæt på bordet og retter Z-offset. AI’en returnerede en fungerende disposition på få minutter; men tre separate valideringer (trekantprofil, ledgrænse, langsom test) fangede tre separate reelle problemer.
Almindelige fejl
- Brug af IK-løsningen uden fælles begrænsninger og tilgængelighedskontrol.
- Ikke klipning af arccos/arcsin-indgange, men producerer NaN i tilfælde af afrundingsfejl.
- Anmoder om kredsløbet uden at begrænse hastigheden/accelerationen og skabe mekanisk stød.
- Ignorerer singularitetszoner og lader ledhastigheder skyde i vejret.
- Springer over overgangen til trapez-trekant profil på kort afstand og beregner det forkerte tidspunkt.
- Udførelse af den første orbitaltest ved fuld hastighed og uden nødstop.
Sammenfattende
- Fremad kinematik har en enkelt løsning; invers kinematik kan producere flere, ikke-eksisterende eller uendelige løsninger.
- IK-løsninger er nødvendigvis filtreret i forhold til fælles grænser, tilgængelighed og singularitet.
- Baneplanlægning; Den bruger bløde, grænse-kompatible profiler såsom trapezformet eller S-kurve.
- På kort afstand skifter profilen fra trapezformet til trekantet; dette skal håndteres i koden.
- AI fremskynder matematik; Grænserne og den fysiske installationskontekst skal indtaste prompten.
- Den nye bane køres altid for første gang med lavt hastighedsforhold og tilgængeligt nødstop.
Ansøgningsopgave
Vælg en to- eller treleddet armmodel (med reelle eller imaginære ledlængder og ledgrænser). Få AI til at generere en invers kinematikfunktion og en baneplanlægger med denne sammenhæng. Derefter: (1) kontroller manuelt IK-outputtet med et kendt mål (sætter du vinklerne tilbage og vender tilbage til samme punkt som FK'en), (2) tester, at koden fanger dem ved at give mindst ét utilgængeligt punkt og én fælles grænse, der overskrider målet, (3) kontroller, at omløbstiden på kort afstand viser sig at være rimelig. Skriv ned, hvor mange valideringsproblemer du fandt i den første version af koden, og hvilket lag der fangede hvert enkelt.