3D optimalizálás - fejlesztőt keresünk
 Kedves Prog.Hu közösség!
A fejlesztőt keresünk, aki szerződés alapján elkészítené az alább feladat ellátását biztosító alkalmazást:
Cégünk több fajta, nagyméretű, előre meghatározott dobozokban exportál termékeket. A szállító járművek bár különbözőek, méretük, és a szállítási díj előre meghatározott. Nekünk a rendelés állomány alapján kell kiszállítanunk a termékeket. A nagyméretű dobozok optimális elrendezését (több sor, oszlop, különböző méret, bizonyos dobozokat c.. |
| valaki kapott plusz infot? vagy esetleg mar el is vallalta valaki a melot? |
| És akkor jön még a rakodás milyensége. Raklapokon pakolják fel az árut? Vagy kézzel külön-külön dobozonként. A raklapos pakolás targoncával történik és ott a szélesség és hosszúság általában adott.(Igaz, ha jól emlékszem két vagy háromfajta raklap van, de ez minimális eltérés.) Max a magasság változik. Ha külön külön dobozonként, arra meg már pár hozzászóló beszámolt. Meg mellette még ott van az útvonalterv is. Ezt is már jó néhányan leszögezték. Még annyit a raklapos pakolásokat általában lezsúgorfóliázzák, így nincs mozgástere, vagy minimális. A dobozos megint érdekes. Üdv.: hml |
Amihez én nem értek, de érdekel a dolog, hogy magának a berakodásnak és a kirakodásnak a technikája egyáltalán hogyan történik és milyen megkötést adhat, és hogyan lehet ezt formalizálni?
Lehet-e olyan, hogy ha fent egy hosszú keskeny lyuk marad, akkor nem tudunk bele pakolni, mert 'nem ér el a kezünk a végére'? Kell-e rögzíteni a dobozokat, vagy ha van 'mozgásterük' mozoghatnak? Igazából ez az a rész, amit nem látok tisztán.  |
| ezt pl. eleg fontos leszogezni, hogy van egyaltalan elso kirakodas vagy a szallito auto teljes rakomanya egy helyen lesz kipakolva... |
Arról ne feledkezzünk meg, hogy nem csak a méret és a tömeg számít, továbbá azok amiket nagyon körültekintően még leírtál.
Tegyük fel, hogy tökjól elfér minden csomag, mm pontosan és az első kirakodási helyen ki kell venni egy gyufásdobozt, ami mondjuk legalul és leghátul van. Igaz hogy befért, igaz hogy oda lett szállítva, dehát.. :) |
Ebben tökéletesen egyetértünk.  |
Abban egyetértünk, hogy nem nagyon éri meg ilyesmit egyedileg kifejleszteni. Olyasminek viszont lehet értelme, ha a megrendelő bizonyos hiányosságokat lát a piacon lévő termékekben, vagy bármilyen piaci rést lát (túl drágák a meglévő termékek, stb...) és terméket akar készíttetni, (és mint prototípus felhasználó segíti a fejlesztést) amit árulni szeretne. Ilyenre sok példa van, végülis nagyon sok szoftvertermék így indul.
De hogy valaki azért fejlesztessen egyedi szoftvert, mert túl drága neki a stock szoftver egyetlen példánya, annak semmi értelme nincs általában. |
Ez jutott eszembe. De ha látnám a valós adatokat, (dobozok relatív mérete a rakodótérhez képest, egyforma dobozok jellemző száma, stb...) valós constrainteket, akkor biztos kicsit más intuícióm lenne a dologról.
Pl. érdemes meginterjúvolni azokat, akik kézzel pakolási terveket készítettek eddig
Pontosan ezt írtam le az első megjegyzésemben. Ide nem csak egy szál jedi programozó kell, félmilliokért, meg milliokért, hanem csapat, erőforrás (méghozzá sok), pénz és idő.
Ha egy ember nekiáll, az sok idő, ami nincs, kísérletezgetni, utánaolvasni, megint idő, ami nincs, és millót elkérni egy olyan termékért, ami már van a piacon, ráadásul egy olyat, ami nem is biztos, hogy bevállik. Én nem adnék ki ennyit érte.
Szerintem keressetek már meglévő alkalmazást! Az biztosabb, gyorsabb, és gazdaságosabb is! |
Na szóval, elképzelhető, hogy érdekelne a dolog, de túl olcsón nem vállalnám el, szóval ha találtok valakit aki olcsóbb, ami vlószínű, akkor tárgytalan. Egy olyan alkalamzással, mint ami a linken van, csak a feature mennyiségre gondolva, jó sokat el lehetne bíbelődni, főleg a 3D drag 'and 'drop meg ilyen nyalánkságok miatt.
Szvsz. szerényebb user interfésszel, inkább csak a core algoritmusra, és annak optimalitására koncentrálva olcsóbban ki lehet hozni, de én azért is elkérnék legalább fél milát, de inkább egy milát (ennyi kell, hogy az ember kipróbáljon több algoritmust, utánaolvasson, kísérletezgessen), szóval nem biztos, hogy velem érdemes kezdeni.
Gondolkodtam a feladaton, mert érdekes, a továbbiakban azt írom le, hogy milyen ötleteim vannak így elsőre, ez végülis lehet, hogy kicsit off, ha valakit nem érdekel, ne olvassa el.
OFF
Először is aki nem tudná, egy viszonylag klasszikus NP-teljes problémáról van szó. Pontosabban van a klasszikus bin-packing probléma, és annak egy csomó változata, és közeli rokona, ezt konkrétan 3D packing néven emlegetik. Persze ennek is annyiféle változata lehet a gyakorlatban ahányféle 'megkötést' lehet alkalmazni a dobozok elhelyezésére. (ne fordítsd bizonyos irányba, valamire nem rakhatsz semmit, összsúly korlátos, stb...) Ha egy feladat NP tlejes, az azt jelenti, hogy exponenciális időben triviálisan megoldható tökéletesen, de ez sok dobozra évezedekig futna, és mivel nem ismerünk ezekre a feladatokra gyors tökéletes megoldást, a gyakorlatban heurisztikákat szoktak alkalmazni.
Nekem elsőre a következő ugrott be:
Halmazokat képzezek az ugyanolyan dobozokból.
Pl. van 7 db. 'A' féle dobozom, 6 darab 'B' féle dobozom, 9 darab 'C' féle dobozom.
Kezdetben a nagy téglatestet, a teljes rakodóteret akarom kitölteni:
Megpróbálok többféleképpen nagy téglatestet képezni egyforma dobozokból. Pl. az 'A' doboz négy példányából 3+3=6 féle téglatestet lehet képezni. Nyilván sok egyforma doboz szabályos rácsozatban való lerakása nagyon tömör, szóval sikerrel kecsegtető dolog. (Továbbá a rakodási utasítás egyszerűségét segíti elő.)
Vannak olyan téglatestek, amit szívesen kipróbálok, bizonyos okokból (nagoyn jól illeszkedik a rendelkezésre álló térben valamelyik irányban), de kipróbálok többfélét is.
Szóval egy ilyen nagy téglatestet lerakok egy sarokba. Ekkor azonnal több részfeladat keletkezett. A lerakott téglatestem felett, egészen a plafonig keletkezett egy mini rakodótér.
Rakodótérnek értelmezhetem továbbá a további maradék teret, kettő nagy átlapolódó téglatest uniója: az előtte lévő területé és a tőle jobbra lévő területé.
Ezekre az al rakodóterekre meghívom rekurzívan az algoritmust, úgy, hogy először mindig a legnagyobb al-rakodótérrel (mint téglatesttel) kezdem. Pl az elől lévő térre hívom rekurzívan magam.
Mindezt addig csinálom, amíg már egy doboz sem fér el egy alteremben sem.
Termézetesen közben állandóan backtrackelek, vagyis visszelépek, és kipróbálok különféle opciókat, választási heurisztikákat.
Nyilván lenne egy csomó paraméter, amiket lehetne finomhangolni...
Figyeljük meg, hogy az algoritmusom nem engedi meg az olyan egymásrapakolást, ahol valamin felül túllóg valami.
Ez jutott eszembe. De ha látnám a valós adatokat, (dobozok relatív mérete a rakodótérhez képest, egyforma dobozok jellemző száma, stb...) valós constrainteket, akkor biztos kicsit más intuícióm lenne a dologról.
Pl. érdemes meginterjúvolni azokat, akik kézzel pakolási terveket készítettek eddig. Az ő intuíciójukat is érdemes beépíteni a heurisztikákba: emberi intuíciók + a számítógép képessége a rengeteg változat végigpróbálására = nagyon jó eredmény.
Szvsz. az algoritmus milyensége egy szint felett már alig számít, egy elég jól kidolgozott packing algoritmus és egy világbajnok között, lehet, hogy pár köbdeciméter a különbség.
ON |
<off>
Erről eszembe jut egy sztori, egy "jólképzett" dunai hajósról, aki megjegyezte egy uszály berakodásánál, amikoris vasbetonelemeket daruztak a raktérbe:
"nem érti, hogy miért nem rakodnak tovább, hiszen láthatóan fér még rá.."
Szóval, majd azért figyeljetek oda, hogy mit rakodtok iksz köbméternyit: poranízót vagy higanyt 
</off> |
"Logisztikai, közlekedési, vezetéstechnikai szakemberekre is szükség van"
Nem tudom, én megnéztem a belinkelt alkalamzást. Úgy láttam, hogy a 'requirement'-ek kielemzése egy szakértő és segítőkész ügyfél plusz egy jó programozó kooperációjából megoldható. Nekem úgy tűnt, hogy a szükséges domain tudás nem igényel pár nap tanulásnál többet.
Én inkább harcore programozói algoritmustervezési feladatnak látom a dolgot, ahova olyan programozó kell, aki képes bonyolultabb algoritmusokat is tervezni, képes a témában írt (bin packing) paper-eket értelmezni és felhasználni. Nem hiszem, hogy egy közlekedéstechnikai szakembernek, vagy egy vezetéstechnikai szakembernek sok tere lenne egy hardcore optimalizálási feladatban, ide matematikus vagy programozó kell, (vagy minek nevezik hivatalosan az olyan embereket, akik algoritmusokkal foglalkoznak? Vannak olyan cégek, ahol egyszerűen szoftver mérnököknek hívják őket.)
Persze, webshopos józsikáknak ilyen feladat nem való, ez így van, csak én nem azt értettem programozó alatt. |
Logisztikai, közlekedési, vezetéstechnikai szakemberekre is szükség van, akik a szoftverfejlesztőkkel közösen tudnak együtt dolgozni. Egy ilyen projectet, ha a megbízó cégnek nem áll rendelkezésére ilyen szakember gárda, akkor ezt a feladatot, egy programozó önmagában nem képes megoldani. Ugyanis is itt, nem csak arról van szó, hogy ...írjunk szoftvert, és az majd működni fog. A rakodástechnikában vannak szabályok, technikai akadályok, amiket be kell tartani. Éppen ezért az ilyen feladatokat csak kapcsolatokkal rendelkező cégek tudják elvállalni.
Azért írtam, hogy itt "nem csak programozókra" van szükség, mert ne legyen olyan, hogy jön egy jó szoftverfejlesztő, és azt mondja, hogy "Hmmm...én tudok jól fejleszteni, a 2D/3D-vel nincs semmi baj, megoldjuk." Ez a feladat nem webshop, amit egy sima kis mezei szaki meg tud oldani.
Legalábbis szvsz. |
ugyanis itt nem csak programozóra van szükség.
Itt kíváncsivá tettél, hogy mire van szükség még...
Amúgy természetesen típusfeladatra szerintem is érdemesebb dobozos terméket használni, mint egyedit kifejlesztetni. Kivéve ha a dobozos termékek nem húzhatóak a cégre, vagy integrálási nehézségek adódnak, (és persze van is elég pénz egyedi fejlesztésre.)
|
Egy ilyen alkalmazás elkészítése nagyon drága, főleg úgy, hogy erre vannak ma már nagyon jól kidolgozott szoftverek is. Sőt, külön cégek, amelyek csak ilyenekkel foglalkoznak, ugyanis itt nem csak programozóra van szükség.
Első körben itt érdemes körbe nézni, de található a piacon több hasonló termék is. |
Kedves Prog.Hu közösség!
A fejlesztőt keresünk, aki szerződés alapján elkészítené az alább feladat ellátását biztosító alkalmazást:
Cégünk több fajta, nagyméretű, előre meghatározott dobozokban exportál termékeket. A szállító járművek bár különbözőek, méretük, és a szállítási díj előre meghatározott. Nekünk a rendelés állomány alapján kell kiszállítanunk a termékeket. A nagyméretű dobozok optimális elrendezését (több sor, oszlop, különböző méret, bizonyos dobozokat csak 1 félképpen lehet berakni, minél kevesebb veszteség a jármű térfogatában) jelenleg emberi munkával tervezzük.
A feladat egy olyan alkalmazás készítése, hogy az adott rendelés állományhoz a legolcsóbb szállítójármű mixet kiválasztva, a szállítási kapacitás lehetséges maximális kihasználása mellett, vizuális (könnyen olvasható, megérthető) elrendezési tervet készít a raktáros számára. A szállítási kapacitás maximális kihasználása érdekében lehetséges, hogy az alkalmazás figyelembe vegye az adott rendelést követő rendelésből is teljesítsen.
Arra kérem, hogy akit érdekel az alkalmazás elkészítése írjon a v.gaspar@tencate-enbi.com címre.
Telefonon részletesebben át tudjuk beszélni, specifikálni a feladatot!
Üdvözlettel:
Gáspár Viktor |
|
