avikde / robobee3d Goto Github PK

#42 #45

Also considered a different implementation than direct transcription: Scott said that it probably won't make a huge difference.

• initial implementation #51
• add actuator constraints #56
• working parameter opt #56
• add timestep as an opt variable for the traj
• If some penalty is too high, it just refuses to move. Should debug the line search more in this situation.
• include timestep in the objective

Use x1,...,xN from the previous solution.

For discrete MPC, use averaging?

• try with the nonlinear version of the thrust/strokedev model
• flapping mpc.nb file in mathematica write out the cts dynamics
• find averageable coordinates
• averaging in mathematica
• implement nonlinear version and debug #40
• implement naive linearization
• implement avg version

Seems like the data collection -> kinematics would get more complicated too

unfortunately patrick's left wing produced more lift. possible causes are:

• wing torsion is causing errors

Originally posted by @avikde in #93 (comment)

Follow on from #86

• Open loop stable trajs. Accelerating stroke
• Force added = k x0 so stiffness affects how much more force is needed for maneuverability
• Address the issue of the initial output traj affecting the param opt -- see #103 for the differences between the "scaled up" and "robobee scale" initial param-generated trajs

Concrete:

• use a traj with low and high stroke amplitude (changing wing thrust) such that the passive hinge stays at a good hinge angle.
• compare design with hover and maneuverability - hopefully there is some difference

Try to get and optimize a transmission so that high EMA near midstroke (high drag).

Try ID

and also opt

do it

Follow on from #86

• plot inertial and coupling in a separate plot than inertial (same as before)
• add mw - cbar constraint of some kind <- do this in order to find realistic design to manufacture #101
• tune frequency as a param #102
• try OL sinusoid input with the "scaled up" cbar - what does the traj look like? different output traj better at higher scales? #103
• stick to params where the nonlin transmission helps and pick those params for manuf

Need to make this more interesting:

• leg linkage? to show evolving leg shape
• as a function of actuator mass?

Originally posted by @avikde in #82 (comment)

Can use (41) in the SM in the science robotics 2017 paper.

Options:

• Only final goal point
• A trajectory with cost to each point
• If trajectory tracking is really important (like maybe somersault??) have a running cost: quadratic cost multiplied by dt. Intuitively like an integral control term?

Both of these were already implemented while working on #10 but the latter doesn't really work well. Could debug the failure of the latter more by seeing if an open-loop definitely-feasible trajectory has the same problem. Come back to this after #24

• in somersault #32 going back to over after spinning caused instability. fix
• veldes horizon beneficial?

• implement a traj following task in the pybullet sim #17
• implement a classical controller (pakpong?) to solve it
• LQR controller #22
• implement the thrust/strokedev MPC controller #9 to compare

Visualize somehow

After #133

Do we need to vary Rpow while doing this?

• second-order deriv? ignore k=1?
• get collocation to actually work?

Related to #84

Implement all these options:

• reuse prev solution to propagate forward
• integrate twist forward (like in legged)
• SQP #23

Right now the planar tests are using a simplistic dynamics iteration which might add further instabilities large timesteps.

• Could use Jafferis (2016). A simplified model would basically be a scaling of voltage to torque.
• Place this in FlappingModels3D.py
• Also stroke force controlled needs more robustness #14

• move a piezo #52 #83
• velocity sensing
• controlled flap pattern with some knot points
• MAVlink interface #55

For #88

• Need to widen airframe
• new base plate

TODOs:

• base plate manufacturing
• airframe assemble with nonlin transmission
• wing design/manufacturing

Transmission design is possible

• transmission in w2d_parameters.nb at the end
• wing AR #105 (comment)

Tried to debug top right a bit #127 (comment). It may be due to

• wing AR constraint lin at too-small cbar
• some other constraint?

To replicate; debug why freq, Aw do not go as expected with higher minal.

• try bounding everything not infinity

Story for paper: making it easier for beginners to design this kind of robot without domain knowledge. Difficult for robobee. related to #88

• smaller design: use same actuator at half the voltage. can just use the scaling lift plot and pick 40mN.
• multiple wings vs larger wings vs. propeller?? (relate to octowing?)
• larger actuators? limit of piezo vs EM

Helped by #119

• discrete enter HAMR actuators for larger opt
• think about greater number of wings

Learnings about parameters while working on #10

• tuning parameters: weights, N, dt, eps_abs, eps_rel
• longer N => problem harder to solve => infeasible result more likely
• shorter N and/or longer dt => instability more likely
• eps_i lower => infeasible more likely (TODO: needs more testing)

Todo:

• reason about units for wxi, wui and reduce those to two scalars?
• reduce the number of parameters by scaling weights

From working on #33:

It is sensitive to:

• dt
• N
• weights in hover phase

Transition to hover phase: should switch to sequential composition

While working on #10 got Failed to find a finite solution from scipy solve_discrete_are

Use the UART for a mavlink interface to the board

• add c library to build
• disconnect UART from printf
• receive heartbeat using pymavlink
• implement the log download messages and try to download a test array
• https://docs.qgroundcontrol.com/en/analyze_view/log_download.html

Example while working on #35 if wu is increased

123 [ 0.38 -0.73 43.34  0.46 -1.71 40.66] [-0.32 -8.06]
124 [ 0.39 -0.74 43.54  0.57 -1.6  -8.39] [  248.46 -6307.31]

Then it fails with "maximum iterations reached"

• debug that l, u are correct
• debug constraint violation #37
• manually rescale the problem to have larger magnitudes
• (maybe) port to cvxpy to try different solvers -- GUROBI

Debugging constraint violations in #63 revealed that the violations were fairly small.

What is wrong with the dynamics that is causing infeasibility? Things that appear to affect it:

• timestep
• eps tolerance

Could use OSQP infeasibility certificate: does it mean anything?

• track points and trajectories #7
• handmade somersault #10

Introduced by #102

Dynamical feasibility:

• thought it was covered by H*p = u
• but that does not cover pos,vel consistency?

all terms in H that depend on vel need to be scaled

• in HMq, Hdamp, σ̇o appears a few times
• ds ~= (s' - s)/dt (first order)
• may need 3 element approx of second deriv s1-2*s2+s3 or something like that?

Have velocities to start. This must be satisfied: dsnew = dsold*dtold/dtnew.

• currently have [Hi Hni] * [pt; dt*pt]
• new will need [Hdti Hdt0 Hdt] * [pt/dt; pt; pt*dt]
• paramAffine needs to group terms with vels separately:

paramAffine H components

• observe that Hi (inertial) ~ vel (seems true; may need to prove TODO)
• Hi -> Hi*dtold; and then multiply it with pt/dt instead of pt
• Hni = Hni_pos + Hni_vel. Hni_vel -> Hni_vel*dtold
• then Hdti = Hi*dtold
• Hdt0 = Hni_vel*dtold
• Hdt = Hni_pos

TODOs:

• affineTest with the decomposition above
• after opt finishes, convert vels by doing vel *= dtold/dtnew

• Check if the flight data from that data can be used directly
• Actuator specs: check max displacement - to tell Robert

Try to get actuator moving

• First try to move the one connected to a transmission+airframe
• Then figure out airframe for the other one if I want to try the new transmission

Noticed while working on #133

To replicate

• run with uinfnorm
• compare result uinf with ret["s"] - ret["s"] was significantly lower. Something may be wrong with the constraint?
• Additionally, changing the weight for uinf (last elem of R) was not changing J

Without uinfnorm it does not pick nonlin transmission

From Chen(2016) Table 1 data: looks like Ixx, Izz (the two wing inertia params) both scale linearly with spar width (mm)

Based on this, maybe it makes sense to produce mspar and mwing both from spar width as the parameter. spar width, cbar, R -> can they together effectively predict Ixx, Izz.

Comparison of physical parameters in Chen (2016) IROS paper

	chord length	R (wing length)	T	mwing (dspar)	NOTES
Ixx	x	x		X	see below
Izz	x	x		X	Observed affine relation between Ixx,Izz from [Chen (2016)]- makes sense to replace with a single lumped "mwing"
AR		X
r1 (spanwise first moment)					n/a planar
LESR					n/a planar
size	X	X

Additionally, the dynamics equations only contain T and R in the combination T/R and can be replaced by a single parameter.

SHOW

Conclusion: we only need two params:

• mwing/dspar - note that Ixx ~= asd

Plots for comparison

Chen (2016)

• Fig 6 - increased mwing. but they also change the traj (freq)
• Fig 9 - AR increase means increase in R - since R only appears as T*R, increased R means increased T.

Chen JFM (2016)

• could say that we can pick what phase shift we want, and modify design to get it, instead of trying different frequencies --> shifting function added in #100; did not improve results much

Originally posted by @avikde in #75 (comment)

Related to #88 (comment)

• cure 1 stack A cut files
• cure 1 stack B cut files
• cure 1 stack A cutting
• cure 1 stack B cutting
• cure 1 heat press
• cure 2 top cut files
• cure 2 middle cut files
• cure 2 press
• release cut files

Determined that the problem here #119 (comment) is normal, and this is to be expected (discussed with Noah).

In order to not make it just prefer higher frequencies, should limit mechanical power somehow.

This is a prereq for #117

find previous issue

• found before that helps more at lower Qdt? check

There is a placeholder already there

We can do some experiments for this validation:

• normalizing for stroke amplitude, compare hinge amplitude this would validate hinge stiffness/damping
• fixed base, torque/voltage input for stroke, and compare stroke angle this would validate actuator stiffness etc.
• open-loop flights

Related: efforts for more modeling #8 #3

Items to do in the future:

• Most of the error in traj reconstruction (use traj1, vs. old traj + Δy) was due to Fext_pdep -- with false, there was a lot of error, but with true, they both yield exactly the same unactErr. What does this mean aboout the overall strategy?
• Better version of fixTraj() that does not just go and apply the inputs from 1..N, and instead does something better

Originally posted by @avikde in #80 (comment)

Also, see #96 (comment) for two more problems caused by fixTraj

• traj becomes asymmetric
• σomax gets exceeded

Applied to 0 at the moment

Should probably happen after #2

• scale correct, rough aero forces correct #6
• flapping kinematics #11
• Flying in pybullet #13
• stroke to force control #14

Ha and Coros.

Choice is in magnitude of Delta x.

Delta p chosen smallest s.t. IFT constraint is maintained.

Current solution is just stepping in that direction (still only one step size param).

• plots against frequency
• plots against voltage

actually could just be one plot

Also do this plot for nonlin vs. lin transmission - Noah things that green is normal, blue would be nonlin.

• IP balance using LQR
• Visualize value function
• TSD anchoring 2x Q2D #50
• anchoring in body frame vs. world frame? see notes
• anchoring deals with Coriolis terms?
• coord change to double pendulum or acrobot
• compare MPC performance with smaller horizon, uninformative value func