15 May

Blender RoCo: Electroprogrammatic Interface Update

Li-Wei Chi

Blender Interface Update: For the past couple of weeks, I have been working on the electroprogrammatic interface for Blender RoCo. Here are some issues that I have encountered, some of which I have solved and others I have some ideas of how I am going to approach solving. Before the list, I would like to remind you guys what I am trying to accomplish with this project. So, there are two sides to this project: the implementation side and the user interface side. The main difference between the two is that the implementation side should be purely functional, that is without side effects. For those who might not know what side effects are. Side Effects are changes to some state outside the currently executing context. So a simple example would be that a function call alters a global variable, thus changing the state of the program that would potentially alter the behavior of the function when it is called the next time. So, in essence, a function or program is without side effects if everytime they are called, the result returns the same.

The implementation side should be functional since once users have constructed the topology of their electricprogrammatic designs the output code generation and electrical wiring instructions should be a pure function that can be call to generate these results. This pure function is obtained by traversing through the user-constructed node tree, which is actually a RoCo component containing subcomponents that are connected to one another. RoCo keeps track of connections and the passing of parameters between subcomponents.

The user interface side would encapsulate all the side effects (user interactions and user inputs). Upon user changes, we would map the changes to RoCo API calls (constrain parameters, add connection, remove subcomponent, …etc). Then the user-constructed node tree is traversed again, but only through the parts that have changed since the last construction.

Status quo: Problem 1: Polymorphism in Blender is limited since Blender manages the data. So subclasses that call on inherited functions to change their states is prohibited. Work around 1: The construction of the nodes itself in the interface can be abstracted into just one class with inputs, outputs, and fields controlled by different operators (so instead of having many classes for different nodes, we would have many operators that operate on a generalized node class) Mixin class provides a way for classes to share methods and code reuse

… more to comeBLOG POST: Blender Interface Problems to Solve: For the past couple of weeks, I have been working on the electroprogrammatic interface for Blender RoCo. Here are some issues that I have encountered, some of which I have solved and others I have some ideas of how I am going to approach solving. Before the list, I would like to remind you guys what I am trying to accomplish with this project. So, there are two sides to this project: the implementation side and the user interface side. The main difference between the two is that the implementation side should be purely functional, that is without side effects. For those who might not know what side effects are. Side Effects are changes to some state outside the currently executing context. So a simple example would be that a function call alters a global variable, thus changing the state of the program that would potentially alter the behavior of the function when it is called the next time. So, in essence, a function or program is without side effects if everytime they are called, the result returns the same.

The implementation side should be functional since once users have constructed the topology of their electricprogrammatic designs the output code generation and electrical wiring instructions should be a pure function that can be call to generate these results. This pure function is obtained by traversing through the user-constructed node tree, which is actually a RoCo component containing subcomponents that are connected to one another. RoCo keeps track of connections and the passing of parameters between subcomponents.

The user interface side would encapsulate all the side effects (user interactions and user inputs). Upon user changes, we would map the changes to RoCo API calls (constrain parameters, add connection, remove subcomponent, …etc). Then the user-constructed node tree is traversed again, but only through the parts that have changed since the last construction.

Status quo: Problem 1: Polymorphism in Blender is limited since Blender manages the data. So subclasses that call on inherited functions to change their states is prohibited. Work around 1: The construction of the nodes itself in the interface can be abstracted into just one class with inputs, outputs, and fields controlled by different operators (so instead of having many classes for different nodes, we would have many operators that operate on a generalized node class) Mixin class provides a way for classes to share methods and code reuse

… more to come

Next Post Previous Post

Search

Popular Tags

foray origami robots blimp ducky vr edg SLAM computer vision computational design roco slam Origami rocolib arduino RoCo design Robot Compiler simulation Motion Planning autonomy edg-model mesh reinforcement learning; multi-agent; mean-field; logics create; kalman filter; motors imu friction mesh network tank esp32 networking contacts multi-agent pushing auxetic machine learning dynamics esp now visual processing wireless control communication webapp pcbs structure ROCO i2c path planning cars Robotica reinforcement learning computer skill openmv test motor dataset visual DARPA odometry Battery surface structure power consumption dash port-arrays modeling origami paper frequency diversity semantic infrastructure auxetics feedback gondola machine vision Consensus bistable auxetic controller gestural intuition mixed reality unit cell robot crawler gestural interface open house network create; kalman filter; EM; refactoring 4-wheeled darpa; create; icra2021 apriltags lidar logic control FORAY perception Quantum Information crazyflie 433mhz optimization propeller Foray structures sensors environmental design radio DER Kullback-Leibler Divergence lasercutter tutorial von Mises Fisher Distribution IR simulink legs project management localization distributed optimization blynk Auxetics painlessmesh experiment results offline reinforcement learning exam research proposal altimeter thrust PCB sensor fusion gate or webots multi-agent path planning UAV RL integration test arnhold joystick balloon test vision processing pushing problem modeling contacts mesh networking motor configuration nodemcu swarm object detection fusionbot ros2 rviz2 gazebo conference matlab arduino nano decentralized surfaces keyboard IROS Integrated Demo throughput peripheral device paper review reinforcement learning; motorized boats Writing slam; paper review rhino Short Post range distance surp origami robot nylon pvdf elastic polymers plastic hot plates reinforcement learning; multi-agent; mean-field; game theory; mean field; reinforcement learning current reinforcement learning; multi-agent; Xbee Zigbee robot compiler spi contact neural network dynamic modeling quasi-static modeling edg-examples Kalman Filter port-array von Mises Fisher von Mises-Fisher literature review multipack car Zero Elastic Energy modes swarm control solar cars system ID serial monitor edg-ide Discrete Elastic Rods ceres debug Consensus Algorithms coriolis force dynamic model proposal wtf deep learning pdms interpolation wireless signal strength reinforcement learning; multi-agent; decentralized misc reinforcement learning; multi-agent; mean-field; stationary demo video flytrap papers steering structured field pivoting differential power detectionrate color shape edg-refactoring pain python vision Machine Learning Q-Learning Model-Free release conferences quasi-static pushing liquid crystal elastomer nonholonomic systems iot grant feedback-controlled controls trajectory optimization surface contact Characterization tool ML multi-agent path finding Liquid Crystal Elastomers Learning kinematic_model reservoir computing 2.4 GHz concept 433 MHz Bayesian Network creative Computer skill internal silicone integrated system instance segmentation marginal cost pricing bootstrapping Bayesian networks ensemble methods offline Rl hardware manipulation COVID 19 paper cutter ESP32 kalman filter; multi-robot state space delta tolling buoyancy chiral square unit cell pressure distribution model prediction thrust configuration grid fabrication firmware protobuf #activecapturingmechanism #claw 3D-CHESS; kalman filter boxboat tracking model-based RL von Mises Distribution slam; flowchart; spring-mass 3D-CHESS; 433 rssi signal strength multirobot system writing in-situ design buoyancy equations boat deployment cell cameras der newton's method Barycenter Euler-Bernoulli beam sma-based actuator game theory Bessel functions von Mises-Fisher Distributions ide HDL board design battery current sensor ZMP center of friction Multi-Agent Systems code balloon semantic segmentation MIMO communications ICRA ICML guassian processes probabilistic neural networks graph generators MBRL batch learning ros edg-compiler multirobot optitrack adaptive control motor driver submission DNN kalman filtering point cloud 2.4ghz latency scenic codesign presentations machine training preliminary exam multiple devices inkscape material multi-object tracking ICLR Python actuation catching mechanism integration flapping color_segmentation lab_data result segmentation on multiple object and centers finding competition prelab multiple blimps pid defender Synthesizable Radio 3d printing kalman filter motor distribution barometer detection lift force depth estimation cad solidworks design tool pixracer pixhawk ardupilot flight controller regression fly test sensor selection