Gevinster:
- Evne til å sette opp og løse fremover/invers kinematikk og baneplanleggingsproblemer ved hjelp av AI
- Evne til å produsere sikker bane ved å gi robotleddgrenser, hastighet og akselerasjonsbegrensninger som kontekst til ledeteksten
- Evne til å numerisk og fysisk verifisere kinematisk og baneutgang produsert av AI
Å bringe griperen på enden av en robotarm til et bestemt punkt i rommet, i en bestemt orientering; Det høres enkelt ut, men det er kinematiske ligninger, leddgrenser, singulariteter og baneplanlegging bak. Her bruker mekatronikkingeniøren trigonometri, lineær algebra og kontrollteori sammen. Kunstig intelligens er et kraftig hjelpemiddel i denne prosessen: den kan etablere foroverkinematiske ligninger, foreslå løsningstilnærminger for invers kinematikk, parameterisere en bane i henhold til hastighets-/akselerasjonsbegrensninger. Robotikk er imidlertid et av områdene innen mekatronikk med høyest fysisk risiko; Hvis en vinkelsekvens generert av AI sendes til roboten uten verifisering, kan armen treffe seg selv, miljøet eller operatøren. I denne enheten vil vi se hvordan du setter opp og verifiserer kinematikk og baneplanlegging med AI.
Fremover og invers kinematikk
Foroverkinematikk (FK): Finne posisjon og orientering av endeeffektoren hvis leddvinklene er kjent. Det er bare én løsning, den er direkte.
Invers kinematikk (IK): Hvis ønsket posisjon til sluttfunksjonen er kjent, finne leddvinklene som vil gi dette. Den har vanligvis mer enn én løsning (som albue opp/ned), noen ganger har den ingen løsninger (uoppnåelig punkt), noen ganger har den uendelige løsninger (singularitet).
konsept
input
utgang
Antall løsninger
Fremover kinematikk
leddvinkler
Ekstrem posisjon/orientering
singel
Invers kinematikk
Ekstrem posisjon/orientering
leddvinkler
Flere/ingen/uendelig
For en to-leddet plan arm kan invers kinematikk settes opp i AI og verifiseres 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 # Tilgjengelighetssjekk: er punktet i arbeidsområdet? hvis np.sqrt(r2) > (L1 + L2) eller np.sqrt(r2) < abs(L1 - L2): heve ValueError("Punkt er utenfor det tilgjengelige arbeidsområdet") cos_t2 = (r2 - L1**2 - L2**2) / (2 * L1 * L2) cos_0t2, -1s_0, klipp 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(t1degrees:degrees(t1) L1=L2=1, mål (1,1) -> forventet t2=90 graderstrykk(inverse_kinematik_2r(1.0, 1.0, 1.0, 1.0)) # ~ (0.0, 90.0)
De kritiske linjene her er der AI ofte hopper over: nåbarhetssjekk (er punktet i arbeidsområdet) og `np.clip` (hindrer arccos-inndata fra å gå utover ±1 på grunn av avrundingsfeil). Uten disse to beskyttelsene vil koden produsere NaN eller krasje på et ugyldig punkt.
Tips: Når du ber om IK-oppløsning, fortelle AI tydelig om å "legge til tilgjengelighetskontroll og begrense arccos-inngang til klipp". Disse to linjene forhindrer de stille feilene som gir mest hodepine i feltet.
Fellesgrenser, singularitet og flere løsninger
Hvert ledd i en ekte robot har et vinkelområde (f.eks. -170° til +170°), en fartsgrense og en akselerasjonsgrense. Selv om IK gir en matematisk gyldig vinkel, kan den ikke brukes hvis den vinkelen er utenfor leddets fysiske rekkevidde. I tillegg faller roboten i singularitet i noen konfigurasjoner: to akser er på linje, en frihetsgrad går tapt, og leddhastigheter prøver å gå til det uendelige for en liten spissbevegelse.
Derfor er ikke HR-løsning alene nok; Hver løsning må bestå et akseptabilitetsfilter:
def solution_gecerli_mi(acilar_deg, limits_deg): """smerter: [t1,t2,...], grenser: [(min,maks),...]""" for smerte, (amin, amax) i zip(acilar_deg, limits_deg): hvis ikke (amin <= smerte <= amax): returgrad False, f:}Jofint-grense overskredet. ({amine},{amax}) bortsett fra" 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], #Jointals limit overskredet...')
AI kan gi den "matematiske" løsningen til IK; men felles grenser og unngåelse av singularitet er spesifikke for systemet ditt og må gis som kontekst til ledeteksten.
Baneplanlegging
Å få roboten fra punkt A til punkt B handler ikke om å tegne en rett linje mellom to vinkler. Plutselig hastighetsendring skaper mekaniske støt og vibrasjoner. I stedet brukes myke profiler: trapesformet hastighetsprofil (konstant akselerasjon–konstant hastighet–konstant retardasjon) eller S-kurve (mykere, der akselerasjonen også er begrenset). Når du får AI til å generere en bane, må du oppgi målet, varigheten og begrensningene.
import numpy som npdef trapez_yorunge(q0, q1, v_max, a_max, dt=0.01): """Trapesformet hastighetsprofil for et enkelt ledd. Posisjonsmatrisen returneres.""" distance = abs(q1 - q0) retning = np.sign(q1 - /speed_max._speed_max._0) t_max_speed_max. * a_max * t_speed**2 if 2 * distance_speed > distance: # trekantprofil (v_max kan ikke nås) t_speed = np.sqrt(distanse / a_max) t_constant = 0.0 v_peak = a_max * t_speed else: t_constant =peak = * v_max - t_max T = (avstand v_max)2 2 * t_accelerate + t_constant t = np.arange(0, T, dt) # ... posisjonsberegning for hver t (basert på akselerasjons-/konstant-/retardasjonsfaser) returnerer t, T, v_peak, varighet, vz = trapesformet_trajectory(0.0, 0, max. 60. a_max=120.0)print(f"Total varighet: {duration:.3f} s, topphastighet: {vz:.1f} grader/s")
Den logiske sjekken her er denne: hvis avstanden er kort, vil motoren aldri nå v_max og profilen vil snu fra trapesformet til trekantet. Hvis AI-en går glipp av denne tilstanden, vil feil varighet bli beregnet for korte bevegelser. Du kan bekrefte dette ved å teste koden med en kjent verdi (for eksempel en veldig kort avstand).
Svak forespørsel / sterk forespørsel
SVAK:"Skriv en bane som tar robotarmen fra A til B."(Ingen begrensning: fartsgrense? akselerasjon? leddavstand? Blind utgang.)STERK:"Generer en punkt-til-punkt bane i leddrom for en 6-akset robot. Hastighetsgrensen for hvert ledd er 90 grader/s, akselerasjonsgrensen er gitt 180 graders tabell, bruk 180 graders tabell. hastighetsprofil, hvis avstanden er kort, faller inn i en trekantet profil.
Verifikasjon: Fra simulering til robot
Banen generert av AI verifiseres i denne rekkefølgen før du går til roboten:
- Numerisk: Er leddvinkelen, hastigheten og akselerasjonen for hvert trinn innenfor grensene?
- Kollisjon: Kolliderer armen langs banen med seg selv eller omgivelsene (visualisere/simulere om mulig)?
- Singularitet: Går banen gjennom et singularitetsområde (nærmer den jakobianske determinanten null)?
- Sakte maskinvaretest: Betjen roboten med lav hastighet (f.eks. 10 %) og overvåk den visuelt.
- Gradvis hastighetsøkning: Når alt er bekreftet, øker hastigheten trinnvis til den nominelle verdien.
Forsiktig: Når du starter en robot med en ny bane for første gang, bør hastighetsoverstyringen alltid være lav og nødstoppet skal være tilgjengelig. Selv om AI-utgangen er "matematisk riktig", vil en forskyvning, omvendt akse eller kabelhake i det fysiske oppsettet bare bli avslørt med langsom testing.
Mini etui
Automatiseringsingeniør Ece ber AI om en banekode i fellesrom for en plukk-og-plasser-applikasjon. AI produserer en trapesformet profil, men når Ece tester en kortdistansebevegelse, ser hun at tiden er negativ: koden håndterte ikke det trekantede profiltilfellet der v_max ikke kan nås. Ece korrigerer dette ved å gi beskjeden "hvis avstanden er kort, fall inn i den trekantede profilen". Den kjører deretter leddvinklene gitt av AI gjennom sin valideringsfunksjon mot sin egen grensetabell og finner ut at ledd 5 ønsket +125° på ett punkt, mens grensen var +120°. Han planlegger banen på nytt og overvåker den, denne gangen kjører han roboten med 10 % hastighet. I første runde ser han at griperen kommer for nær bordet og korrigerer Z-offset. AI returnerte en fungerende disposisjon på få minutter; men tre separate valideringer (triangulær profil, leddgrense, langsom test) fanget opp tre separate reelle problemer.
Vanlige feil
- Bruker IK-løsningen uten fellesbegrensninger og tilgjengelighetskontroll.
- Ikke klipper arccos/arcsin-oppføringer, men produserer NaN i tilfelle avrundingsfeil.
- Be om bane uten å begrense hastighet/akselerasjon og skape mekanisk sjokk.
- Ignorerer singularitetssoner og lar leddhastigheter skyte i været.
- Hoppe over trapes-trekantprofilovergangen på kort avstand og beregne feil tid.
- Gjennomføring av den første orbitaltesten i full hastighet og uten tilgang til nødstopp.
Oppsummert
- Fremover kinematikk har en enkelt løsning; invers kinematikk kan produsere flere, ikke-eksisterende eller uendelige løsninger.
- IK-løsninger er nødvendigvis filtrert når det gjelder fellesgrenser, tilgjengelighet og singularitet.
- Baneplanlegging; Den bruker myke, grensekompatible profiler som trapesformet eller S-kurve.
- På kort avstand endres profilen fra trapesformet til trekantet; dette skal håndteres i koden.
- AI setter fart på matematikk; Grensene og den fysiske installasjonskonteksten skal angi ledeteksten.
- Den nye banen kjøres alltid for første gang med lavt hastighetsforhold og tilgjengelig nødstopp.
Søknadsoppgave
Velg en to- eller treleddet armmodell (med reelle eller imaginære leddlengder og leddgrenser). Få AI til å generere en invers kinematikkfunksjon og en baneplanlegger med denne konteksten. Deretter: (1) verifiser IK-utgangen manuelt med et kjent mål (legger du vinklene tilbake og går tilbake til samme punkt som FK), (2) tester at koden fanger dem ved å gi minst ett utilgjengelig punkt og en felles grense som overskrider målet, (3) kontroller at omløpstiden på kort avstand viser seg å være rimelig. Skriv ned hvor mange valideringsproblemer du fant i den første versjonen av koden og hvilket lag som fanget hvert enkelt.