Skip to content
Snippets Groups Projects

Repository graph

You can move around the graph by using the arrow keys.
Select Git revision
  • alv
  • gitlab_ci_podman
  • main default protected
  • mpc
  • pp
  • realtimelogplotter
  • refactoring
  • restructuring
  • rosification
  • viz_fix
10 results
Created with Raphaël 2.2.028Apr2314Mar111098765432128Feb27262422201918171413107654329Jan24232120Dec151312111098765432129Nov272623201918171514131087654131Oct30211816151110973230Sep2924212030Aug23May10Apr926Mar252322212014Jan28Nov2726252322212019181716109876331Oct302625242321201912118some commitmainmaincommiting in case laptop diesregrasping first commit. implementation is so unfinished it can't even be tested yet, but i don't want to accidentally delete something, hence the commitidk when i last commited and idk when i'll commit againrosificationrosificationi am a moron with frames. there goes 4 hours on me being a moron. but its good nowcan navigate mobile yumidone 4 todaystuff makes a bit more sensejesus take the wheelfirst day in the lab - robot moves - control is horrible. rest of the day is for hacking whatever remotely works, tomorrow is about running it and live-patching. it's doablerealyumirobotmanager + dummy publisher and subscribersynclast for today. some debugging necessary for final dual arm cart pulling version, but the greatest hits are there and it should be fine. disjoint control is the worst case and that's totally fine. after debugging this the next step is to bring in localization and start running this on rosarbitrary base AND end-effector following. have to say it's pretty shit lulesome path stuff, qpmanipmaxtests for p2p mpcs are therecommiting just for the readme, will make the missing ocp tests next, and then refactor path planning mpcs to simultaneouly support fixed paths and paths from a path plannerswappable navigation control - if mpc craps out, use clik to bail it out. everything could be improved (individual controllers and the combo), but this seems to be good enoughstill debugging why navigation mpc stops for no reason. almost done with cartesian path following - with correctly formulated QP it solves underactuation. did some nice refactoring of path-following mpcsmobile navigation with drawing works, now it's super easy to test navigation by itselftried and tested now. of course half of the jacobian slicing was wrong lmao. not saying every controller does what it should, but at least the dimensions matchunified control modes, they are also selectable via argument. will need to write tests to make sure every case works as expectedadded dual-arm end-effector self-collision avoidance done through pink. now have a hang of pink, will add in self-collision avoidance for the whole body. first will probably look into posture tasks and similar. key point is pink works within smcmade realur5e manager runnable. there's something evil going on with different inheritances where the attributes inherited from a class don't show up in the child class (realur5emanager). i just copy-pasted the initial values in for now to be able run anything, but a correct solution has to be found for the futuremobilebaseinterface and mir by itself now make sense and are usable for experimentation with navigation. the model property needs to be overriden to produce truncated models depending on the control mode to make use of base-only ocp for whole body roobotssolved merge, we're back in main with version 0.3commit before merging onto mainrefactoringrefactoringfixed heron on python3.13fixed point impedance, added testrefactored drawingin the middle of refactoring drawing democart pulling is runnable, but needs some massaging to get going. initialization almost certainly has to be done via disjoint controlsolved a few bugsfigured out what was wrong with the qp formulation of inverse kinematics. documented in-place in code for now, will try to find a better solution during supervision meeting.did run dual arm ik ocp, but there's something evil there. removed final velocity to be 0 because it makes no sense for an mpc, did put a comment to make it optional if there is mpc. wrote what we have and what's missing for RealHeronRobotManagermobile yumi pseudoinverse worksadded comments on what's missinggetting real close to FULLY finalize refactoringsingle arm and heron is runnable, dual-arm not finished by not break the restin the middle of templetizing control loops and putting in dual arm features. i have no idea what works or what broken at the moment. the key next steps are making dualarmwholebodyinterface, probably separating point-to-point motions into different files depending on the robot, and finalizing dual-arm ocps and mpcs