Svenska ElektronikForumet

Jag startar en ny tråd istället.

Har ni lust att hjälpa mig starta upp qpOASES? Det är ett C++ bibliotek men det finns en utbrytning som heter qpOASES_e där e står för embedded. Projektet är gjort i C.

https://projects.coin-or.org/qpOASES/

qpOASES är en QP-lösare och med en QP-lösare så kan man optimera in- och utsignaler för ett reglerobjekt. Exempelvis om ni ska värma ett hus så kanske insignalen kan endast vara 0-100 % och utsignalen är endast 15-25 grader C.

Resultatet man får med en QP-lösare är insignaler som anpassas mot verkligheten. Det kan t.ex vara att man eliminerar dötid, överskjut och svängningar och undantag. Samtidigt som man får det optimerat.

Jag har kollat lite i koden och försökt skriva om den så att man ska behöva bara köra den utan att installera koden. Mitt mål är att få qpOASES_e portabelt i projektform. Då kan jag bara lägga in den i t.ex Kiel, IAR eller Atollic och kompilera. Slippa länka för det vet jag inte hur man gör riktigt.

qpOASES_e hittar ni här
https://github.com/acados/qpOASES

Den minimerar en objektiv funktion med begränsningarna. Vad tror ni? Med våra kloka huvuden ihop så kan vi bygga en Model Predictive Control regulator för inbyggda system. Används flitigt ute på industrin. MPC är "bättre" än en PID om man bara tittar på funktionaliteten och inte kostnaden.

Obs. qpOASES_e använder malloc och free. Men man behöver bara anropa dom en gång till exempelvis vid uppstart. Ska nog inte skada. Den ska dock enligt tillverkarna ha så mycket statisk minne som det går.

https://github.com/acados/qpOASES

Vad det betyder låter jag vara osagt, kanske ingenting, men projektet har inga commits på över ett år, EN stjärna och NOLL forks. Vet du att det fungerar? I alla hörnen också?

Med tanke på att jag har inte hittat något annat bibliotek som sägs fungera för inbyggda system. Dessutom så är projekt som är gjort i C riktigt igenomtänkta och välgjorda. Det tar många timmar att skriva C-kod om vi ska titta på numeriska metoder.

Jag förlitar att qpOASES_e fungerar bra.

dito. DanielM: Det ringer några varningsklockor här, du jobbar med en algoritm som är känd för att vara ostabil, via ett biblioket vars status såvitt vi kan bedöma just nu är okänt, med aritmetik med begränsad precision. Du reder säkert ut det här, men ta det lite försiktigt!

QP-lösare är inte ostabila. Vart har du hört ifrån det?

Jag pratade om RLSen.

DanielM skrev:Med tanke på att jag har inte hittat något annat bibliotek som sägs fungera för inbyggda system. Dessutom så är projekt som är gjort i C riktigt igenomtänkta och välgjorda. Det tar många timmar att skriva C-kod om vi ska titta på numeriska metoder.

Jag förlitar att qpOASES_e fungerar bra.

Språket har inte mycket med kvalitén att göra. Det går att göra fel i alla system och språk, speciellt om ansvarig inte har bra koll.

guckrum skrev:Jag pratade om RLSen.

Det finns många versioner utav RLS. Jag använder versionen som säljs kommersionellt från https://www.firstcontrol.se/
Notera att Microcontroller XC har över 30 år på nacken, ännu fungerande.

Är det bara jag som tänker på Rasperry Pi när jag ser Microcontroller XC05IX

hummel skrev:

DanielM skrev:Med tanke på att jag har inte hittat något annat bibliotek som sägs fungera för inbyggda system. Dessutom så är projekt som är gjort i C riktigt igenomtänkta och välgjorda. Det tar många timmar att skriva C-kod om vi ska titta på numeriska metoder.

Jag förlitar att qpOASES_e fungerar bra.

Språket har inte mycket med kvalitén att göra. Det går att göra fel i alla system och språk, speciellt om ansvarig inte har bra koll.

Det stämmer det du säger. Men att göra ett projekt i C jämfört med ett högre nivå språk brukar visas sig att lågnivåspråk resulterar högre kvalité. Det finns en orsak varför Linux inte har skrivits om till C++, MySQL är C, Java skrevs i C, Python skrevs i C med mera. Ngnix är C.

Vill bara flagga lite att denna tråd hoppas jag inte ska bli en VS programmeringsspråksdebatt eller fokus på andra saker. Detta är bara en förfrågan om vi (de som är intresserad) utav att bygga ihop qpOASES_e för inbyggda system. Största jobbet är redan gjort. Det gäller bara att implementera på ett bra sätt.

Där efter så kan vi köra några reglerexempel och då kan jag visa er hur man kan optimera insignaler för utsignaler. Jag har använt mig av en QP-lösare förut. Bra saker ska jag säga, men avancerat. QP-lösning är väldigt populärt bland universiteten idag.

Skriv i tråden om ni är intesserad.

Jag skulle nog ta C varianten för inbyggda processorer, endast statiskt minne också:
https://projects.coin-or.org/qpOASES/wi ... esEmbedded


Inte så mycket kod så borde vara ganska lätt få igång på stm32

DanielM skrev:

hummel skrev:

DanielM skrev: <SNIP>

Det stämmer det du säger. Men att göra ett projekt i C jämfört med ett högre nivå språk brukar visas sig att lågnivåspråk resulterar högre kvalité. Det finns en orsak varför Linux inte har skrivits om till C++, MySQL är C, Java skrevs i C, Python skrevs i C med mera. Ngnix är C.

C är ett imperativt språk och C++ är ett språk för objektorienterad programmering och med rätt bra verktyg för data-abstraktion. Dessa två språk används för olika saker och kanske inte är lämpade för att lösa samma saker.
Själv har jag utvecklat i mjukvara i C sedan mitten av 80-talet men bara för att jag anser mig kunna det bra betyder inte att det alltid är rätt verktyg för att lösa ett problem.

”Det finns en orsak varför Linux inte har skrivits om till C++”

Japp.
Tänk mängden kod som skulle behöva göras om.
Tiden som skulle krävas.
Och: Resultatet (programmen) skulle fungera precis likadant ändå.

Så det vore ett väldigt meningslöst projekt...

(Jodå, jag vet att det inte var den orsaken som du ville lyfta fram, men konsekvenser handlar sällan bara om 1st orsak. )


Åter till ämnet:

Du borde kontakta en medlem som heter Al_Bundy. Ni delar samma tankar om programmeringsspråk och reglering.
Dessutom håller ni på med väldigt lika projekt. Det skulle kunna bli ett bra samarbete!
(Senaste gången han loggade in var 20 september och då hade du inte varit medlem så länge, så du har nog missat honom..)

Här är hans trådar. Kika där och kontakta honom.
(Vet att du fått tipset, men du svarade aldrig på det.)

svaret blir intressant...
men det kanske inte är hemligt

Rick81 skrev:Jag skulle nog ta C varianten för inbyggda processorer, endast statiskt minne också:
https://projects.coin-or.org/qpOASES/wi ... esEmbedded


Inte så mycket kod så borde vara ganska lätt få igång på stm32

Denna länk har jag tittat på förut. För två veckor sedan fungerade den inte. Vilket var orsaken varför jag länkade GitHub-sidan. Men absolut så ska vi använda från denna källa.

JimmyAndersson skrev:”Det finns en orsak varför Linux inte har skrivits om till C++”

Japp.
Tänk mängden kod som skulle behöva göras om.
Tiden som skulle krävas.
Och: Resultatet (programmen) skulle fungera precis likadant ändå.

Så det vore ett väldigt meningslöst projekt...

(Jodå, jag vet att det inte var den orsaken som du ville lyfta fram, men konsekvenser handlar sällan bara om 1st orsak. )


Åter till ämnet:

Du borde kontakta en medlem som heter Al_Bundy. Ni delar samma tankar om programmeringsspråk och reglering.
Dessutom håller ni på med väldigt lika projekt. Det skulle kunna bli ett bra samarbete!
(Senaste gången han loggade in var 20 september och då hade du inte varit medlem så länge, så du har nog missat honom..)

Här är hans trådar. Kika där och kontakta honom.
(Vet att du fått tipset, men du svarade aldrig på det.)

Tackar.