Re: GSoC 2026 Proposal - Hardware in the loop CI
Joseph George <[email protected]> Wed, 1 Apr 2026 16:42:07 +0530
| Newsgroups | gmane.comp.gnu.radio.general |
|---|---|
| Message-ID | <CAGv1_4Ut-9QE1Whgdf6DmZYaQ6iZ0LE0zM_xfHCH4u=SQUE8aw@mail.gmail.com> |
--0000000000005e2b7f064e6428ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Marcus, =E2=80=8BThanks for taking a look and for the feedback! =E2=80=8BI completely agree that CorteXlab's native Minus API is fantastic = for handling the core node management and scheduling. =E2=80=8BAfter discussing the architecture with Cyrille on the list earlier= this week, I actually updated the final proposal to clarify this exact relationship. My main reason for exploring Labgrid was actually to fill a few specific CI orchestration gaps that I wasn't sure CorteXlab's Minus API handled natively for unattended runners. Specifically: - =E2=80=8BBlocking reservation queue: Ensures concurrent PR jobs don't collide. - =E2=80=8BCrash-safe orphan detection: Uses a heartbeat so a killed run= ner doesn't hold a node locked indefinitely. - =E2=80=8BHardware-agnostic YAML environments: Keeps test scripts decou= pled from CorteXlab's specific node identifiers. *=E2=80=8BI noted in the proposal that the plan is to assess this during Co= mmunity Bonding. If introducing Labgrid is too heavy or the wrong fit for the GNU Radio CI ecosystem, I am 100% on board with dropping it and just building a lightweight custom shim around the Minus API to handle the queueing and heartbeats.* =E2=80=8BReally appreciate you taking the time to review the concept! I'd l= ove to hear your thoughts on this layered approach. =E2=80=8BBest, Joseph On Wed, 1 Apr, 2026, 16:20 Marcus M=C3=BCller, <[email protected]> wrot= e: > Don't think labgrid is the kind of thing that helps here, much. > > On 2026-03-31 2:09 PM, Philip Balister wrote: > > On 3/30/26 4:16 AM, Cyrille Morin wrote: > >> Hello Joseph, > >> > >> I read trough your document. > >> Overall, it looks good, it appears to have everything required of the > proposal document. > >> > >> A couple of thoughts: > >> > >> The proposed integrated tests look good and feel like what we would > like to head > >> towards, but being integration tests, they involve a lot of moving > parts, so they might > >> require a lot of tweaking and debugging time to work reliably, which > might push back the > >> integration into the CI pipeline. > >> > >> I've never used Labgrid so I don't know much about what it can or > cannot help with. But > >> it does sound in your proposal to perform many task already done by th= e > platform's > >> systems (booking, health check, ...) You might want to detail where > specifically Labgrid > >> would offer new and required capabilities > > > > Labgrid would offer a general API to the hardware so the work could > extend beyond > > CorteXlab. It is certainly worth a look to see if it is straight forwar= d > to abstract the > > interface to the underlying hardware. > > > > Philip > > > > > >> > >> Best > >> > >> *Cyrille MORIN* > >> /Ing=C3=A9nieur SED/ > >> /=C3=89quipe MARACAS/ > >> > >> Logo Inria > >> Centre Inria de Lyon > >> > >> Laboratoire CITI > >> Campus La Doua - Villeurbanne > >> 6 avenue des Arts > >> F-69621 Villeurbanne > >> > >> https://team.inria.fr/maracas/ > >> Le 28/03/2026 =C3=A0 14:49, Joseph George a =C3=A9crit : > >>> > >>> Hi Cyrille, > >>> > >>> I have completed the first draft of my GSoC 2026 proposal for the > "Hardware in the Loop > >>> CI" project. > >>> > >>> Draft : Hardware in the Loop CI <https://drive.google.com/file/ > >>> d/1ATLOxq_bvPpG7fizTQtZK-8w_BwadVeF/view?usp=3Ddrive_link> > >>> > >>> A huge thank you to Larry and Philip for the insights. I have > explicitly integrated the > >>> LBNL Node Health Check paradigm to isolate hardware failures from > software regressions, > >>> and I've adopted Labgrid as the core hardware orchestration layer to > manage the > >>> CorteXlab USRPs. > >>> > >>> I would greatly appreciate any feedback from the community, > >>> > >>> Thanks for your time and guidance! > >>> > >>> Best, Joseph George > >>> > >>> > >>> On Thu, 26 Mar 2026 at 22:23, Cyrille Morin <[email protected]> > wrote: > >>> > >>> Hi Joseph, > >>> > >>> Welcome! > >>> > >>> Feel free to share your draft here on the mailing list, for > >>> feedback by members of the community, that's the right place > >>> > >>> I don't have a specific format for the tests scenarios, choose > >>> what you think is best/more readable/most relevant. > >>> But do look at the GSoC Student info on the wiki if you haven't > >>> already: https://wiki.gnuradio.org/index.php?title=3DGSoCStudentI= nfo > >>> <https://wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo> > >>> > >>> *Cyrille MORIN* > >>> Le 26/03/2026 =C3=A0 15:56, Joseph George a =C3=A9crit : > >>>> Hi Cyrille, > >>>> I=E2=80=99m Joseph, an ECE student and the Chair of the IEEE Sig= nal > >>>> Processing Society at my college. I=E2=80=99m putting together a= GSoC > >>>> proposal for the "Hardware in the loop CI" project and wanted to > >>>> quickly say hello. > >>>> > >>>> I have a strong background in bridging DSP theory with physical > >>>> hardware. I recently placed 7th globally in the ICASSP 2026 ALS > >>>> challenge by building domain-driven acoustic biomarker pipelines= , > >>>> and I regularly build hardware projects (like ESP32 navigation > >>>> systems using Kalman filtering for sensor fusion). I'd love to > >>>> help bring GNU Radio's CI tests out of software only simulation > >>>> and onto the physical CorteXlab hardware. > >>>> > >>>> I am drafting my 12-week timeline right now. Is there a specific > >>>> format you prefer for the test scenarios, or a good place to dro= p > >>>> a link to my draft for a quick sanity check before Tuesday's > >>>> deadline? > >>> > > > > > > > --0000000000005e2b7f064e6428ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Hi Marcus,<div dir=3D"auto">=E2=80=8BThanks for taking a = look and for the feedback!</div><div dir=3D"auto">=E2=80=8BI completely agr= ee that CorteXlab's native Minus API is fantastic for handling the core= node management and scheduling.=C2=A0=C2=A0</div><div dir=3D"auto">=E2=80= =8BAfter discussing the architecture with Cyrille on the list earlier this = week, I actually updated the final proposal to clarify this exact relations= hip.</div><div dir=3D"auto"><br></div><div dir=3D"auto">My main reason for = exploring Labgrid was actually to fill a few specific CI orchestration gaps= that I wasn't sure CorteXlab's Minus API handled natively for unat= tended runners. Specifically:</div><div dir=3D"auto"><br></div><div dir=3D"= auto"><ul><li>=E2=80=8BBlocking reservation queue: Ensures concurrent PR jo= bs don't collide.=C2=A0=C2=A0</li><li>=E2=80=8BCrash-safe orphan detect= ion: Uses a heartbeat so a killed runner doesn't hold a node locked ind= efinitely.=C2=A0=C2=A0</li><li>=E2=80=8BHardware-agnostic YAML environments= : Keeps test scripts decoupled from CorteXlab's specific node identifie= rs.=C2=A0=C2=A0</li></ul></div><div dir=3D"auto"><br></div><div dir=3D"auto= "><b>=E2=80=8BI noted in the proposal that the plan is to assess this durin= g Community Bonding. If introducing Labgrid is too heavy or the wrong fit f= or the GNU Radio CI ecosystem, I am 100% on board with dropping it and just= building a lightweight custom shim around the Minus API to handle the queu= eing and heartbeats.</b></div><div dir=3D"auto"><b><br></b></div><div dir= =3D"auto">=E2=80=8BReally appreciate you taking the time to review the conc= ept! I'd love to hear your thoughts on this layered approach.</div><div= dir=3D"auto">=E2=80=8BBest,</div><div dir=3D"auto">Joseph</div></div><br><= div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"g= mail_attr">On Wed, 1 Apr, 2026, 16:20 Marcus M=C3=BCller, <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> wrote:<br></div><= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Don't think labgrid is the kind of thing = that helps here, much.<br> <br> On 2026-03-31 2:09 PM, Philip Balister wrote:<br> > On 3/30/26 4:16 AM, Cyrille Morin wrote:<br> >> Hello Joseph,<br> >><br> >> I read trough your document.<br> >> Overall, it looks good, it appears to have everything required of = the proposal document.<br> >><br> >> A couple of thoughts:<br> >><br> >> The proposed integrated tests look good and feel like what we woul= d like to head <br> >> towards, but being integration tests, they involve a lot of moving= parts, so they might <br> >> require a lot of tweaking and debugging time to work reliably, whi= ch might push back the <br> >> integration into the CI pipeline.<br> >><br> >> I've never used Labgrid so I don't know much about what it= can or cannot help with. But <br> >> it does sound in your proposal to perform many task already done b= y the platform's <br> >> systems (booking, health check, ...) You might want to detail wher= e specifically Labgrid <br> >> would offer new and required capabilities<br> > <br> > Labgrid would offer a general API to the hardware so the work could ex= tend beyond <br> > CorteXlab. It is certainly worth a look to see if it is straight forwa= rd to abstract the <br> > interface to the underlying hardware.<br> > <br> > Philip<br> > <br> > <br> >><br> >> Best<br> >><br> >> *Cyrille MORIN*<br> >> /Ing=C3=A9nieur SED/<br> >> /=C3=89quipe MARACAS/<br> >><br> >> Logo Inria<br> >> Centre Inria de Lyon<br> >><br> >> Laboratoire CITI<br> >> Campus La Doua - Villeurbanne<br> >> 6 avenue des Arts<br> >> F-69621 Villeurbanne<br> >><br> >> <a href=3D"https://team.inria.fr/maracas/" rel=3D"noreferrer noref= errer" target=3D"_blank">https://team.inria.fr/maracas/</a><br> >> Le 28/03/2026 =C3=A0 14:49, Joseph George a =C3=A9crit=C2=A0:<br> >>><br> >>> Hi Cyrille,<br> >>><br> >>> I have completed the first draft of my GSoC 2026 proposal for = the "Hardware in the Loop <br> >>> CI" project.<br> >>><br> >>> Draft : Hardware in the Loop CI <<a href=3D"https://drive.g= oogle.com/file/" rel=3D"noreferrer noreferrer" target=3D"_blank">https://dr= ive.google.com/file/</a> <br> >>> d/1ATLOxq_bvPpG7fizTQtZK-8w_BwadVeF/view?usp=3Ddrive_link><= br> >>><br> >>> A huge thank you to Larry and Philip for the insights. I have = explicitly integrated the <br> >>> LBNL Node Health Check paradigm to isolate hardware failures f= rom software regressions, <br> >>> and I've adopted Labgrid as the core hardware orchestratio= n layer to manage the <br> >>> CorteXlab USRPs.<br> >>><br> >>> I would greatly appreciate any feedback from the community,<br= > >>><br> >>> Thanks for your time and guidance!<br> >>><br> >>> Best, Joseph George<br> >>><br> >>><br> >>> On Thu, 26 Mar 2026 at 22:23, Cyrille Morin <<a href=3D"mai= lto:[email protected]" target=3D"_blank" rel=3D"noreferrer">cyrille.mo= [email protected]</a>> wrote:<br> >>><br> >>> =C2=A0=C2=A0=C2=A0 Hi Joseph,<br> >>><br> >>> =C2=A0=C2=A0=C2=A0 Welcome!<br> >>><br> >>> =C2=A0=C2=A0=C2=A0 Feel free to share your draft here on the m= ailing list, for<br> >>> =C2=A0=C2=A0=C2=A0 feedback by members of the community, that&= #39;s the right place<br> >>><br> >>> =C2=A0=C2=A0=C2=A0 I don't have a specific format for the = tests scenarios, choose<br> >>> =C2=A0=C2=A0=C2=A0 what you think is best/more readable/most r= elevant.<br> >>> =C2=A0=C2=A0=C2=A0 But do look at the GSoC Student info on the= wiki if you haven't<br> >>> =C2=A0=C2=A0=C2=A0 already:=C2=A0<a href=3D"https://wiki.gnura= dio.org/index.php?title=3DGSoCStudentInfo" rel=3D"noreferrer noreferrer" ta= rget=3D"_blank">https://wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo= </a><br> >>> =C2=A0=C2=A0=C2=A0 <<a href=3D"https://wiki.gnuradio.org/in= dex.php?title=3DGSoCStudentInfo" rel=3D"noreferrer noreferrer" target=3D"_b= lank">https://wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo</a>><b= r> >>><br> >>> =C2=A0=C2=A0=C2=A0 *Cyrille MORIN*<br> >>> =C2=A0=C2=A0=C2=A0 Le 26/03/2026 =C3=A0 15:56, Joseph George a= =C3=A9crit=C2=A0:<br> >>>> =C2=A0=C2=A0=C2=A0 Hi Cyrille,<br> >>>> =C2=A0=C2=A0=C2=A0 I=E2=80=99m Joseph, an ECE student and = the Chair of the IEEE Signal<br> >>>> =C2=A0=C2=A0=C2=A0 Processing Society at my college. I=E2= =80=99m putting together a GSoC<br> >>>> =C2=A0=C2=A0=C2=A0 proposal for the "Hardware in the = loop CI" project and wanted to<br> >>>> =C2=A0=C2=A0=C2=A0 quickly say hello.<br> >>>><br> >>>> =C2=A0=C2=A0=C2=A0 I have a strong background in bridging = DSP theory with physical<br> >>>> =C2=A0=C2=A0=C2=A0 hardware. I recently placed 7th globall= y in the ICASSP 2026 ALS<br> >>>> =C2=A0=C2=A0=C2=A0 challenge by building domain-driven aco= ustic biomarker pipelines,<br> >>>> =C2=A0=C2=A0=C2=A0 and I regularly build hardware projects= (like ESP32 navigation<br> >>>> =C2=A0=C2=A0=C2=A0 systems using Kalman filtering for sens= or fusion). I'd love to<br> >>>> =C2=A0=C2=A0=C2=A0 help bring GNU Radio's CI tests out= of software only simulation<br> >>>> =C2=A0=C2=A0=C2=A0 and onto the physical CorteXlab hardwar= e.<br> >>>><br> >>>> =C2=A0=C2=A0=C2=A0 I am drafting my 12-week timeline right= now. Is there a specific<br> >>>> =C2=A0=C2=A0=C2=A0 format you prefer for the test scenario= s, or a good place to drop<br> >>>> =C2=A0=C2=A0=C2=A0 a link to my draft for a quick sanity c= heck before Tuesday's<br> >>>> =C2=A0=C2=A0=C2=A0 deadline?<br> >>><br> > <br> > <br> <br> <br> </blockquote></div> --0000000000005e2b7f064e6428ff--