Posted on

Team Status Report for 4/27

Overall progress:

On the software side, what is left is finishing the software-hardware interface. On the hardware side, we have made the order for the PCB.

Significant risks and risk management:

Risk:  Ensuring the PCB works correctly

Description: When shipping the PCB with PCBWay, we found that it was impossible for the PCB to arrive on time if we wanted it to be fully assembled due to the manufacturer unable to source all the parts. As such, we have to manually reflow parts of the PCB. This is a risk as parts might go wrong during the reflow process.

Severity: If an error happens during the reflow process, our PCB will not work intended. This will likely mean that our final product will only be in simulation.

Resolution: Unfortunately there is not much we can do to prevent this risk. We can only put in as much care as we can when we reflow the PCB.

 

Software tests

  1. Testing that the SLP solver can swing up the pendulum in multiple starting configurations.
  2. Comparing the solution from the SLP solver with an IPOPT solver to ensure the solution is accurate.
  3. Test the SLP solver with gaussian noise on theta to ensure robustness.
  4. Test the SLP solver with gaussian noise on theta dot to ensure robustness.

Hardware tests

  1. Simulating the hardware with LPs (the first, last, and random LPs) given by the software solver and verifying that results match the software solution.
  2. Verifying the circuit behavior matches expectations and ensuring the operation range of the circuit lies within bounds by simulating it.

 

Changes to the existing design:

There are currently no significant changes to the existing design.

Changes to the project schedule:

There are no significant changes to the schedule as we are nearing the end of the semester.

Posted on

Alvin’s Status Report for 4/27

Personal tasks of this week:

Task: Setting up the Raspi-PCB interface

Definition: To communicate between the raspi and the PCB, an interface is needed. Namely, the raspi needs to be able to configure the PCB by controlling switches and digipots on the board, as well as give an input voltage and read an output voltage. Performing these operations will require establishing communication protocols using I2C, SPI, and GPIO.

Completion: I was able to verify that the library CircuitPython works for I2C, SPI, and GPIO by testing with the raspi and the arduino. I am now writing the interface between the Raspi and PCB, using our schematic made by Andrew. I currently have the part for controlling the analog switch and reading the ADC completed.

Next Steps:

Create the remaining interface, including controlling the digipots and writing the high level functions that performs circuit calibration, as well as the process of giving the PCB inputs and configuring it, wait for it to converge, then reading the outputs for a LP.

Overall progress assessment:

The remaining work is on finishing the interface and testing the whole system once the PCB arrives. Slightly behind schedule as the PCB is expected to arrive next week, and it is hard to test the correctness of the interface without it.

Posted on

Team Status Report for 4/20

Overall progress:

On the software side, what is left is finishing the software-hardware interface. On the hardware side, we need to finish the layout for the PCB and send it out for shipping.

Significant risks and risk management:

Risk:  Shipping the PCB on time

Description: Figuring out the routing/layout of the PCB is taking longer than expected. This is partially due to the fact that we need to verify the correctness of different parts of the board.

Severity: If we are unable to finish the layout before next Tuesday, we run the risk of not being able to ship the PCB in time.

Resolution: We are currently putting in as much time as possible to finish the layout.

Risk:  While the circuit seems to work properly, we still need to properly identify what kinds of issues arise in the physically circuit

Description: We were able to predict much of the behavior of the “real world” circuit by using the components specified in the BOM. However, the actual behavior of the circuit will obviously be different

Severity: If the inaccuracies of the physical pcb are not properly accounted for, the circuit can have a variety of errors, including non-convergence and solutions with high error.

Resolution: We are currently modeling the behavior of some of these real-world effects as electrical components. For example, we have capacitors on the op amps that do not exist in the theoretical formulation, but exist in the real world analogue due to the parasitic capacitances. However, there are many more places where these issues can occur. The largest source of error compared to the circuit is the transition from resistors to linpots.

Changes to the existing design:

There are currently no significant changes to the existing design.

Changes to the project schedule:

We are trying to put as much time as we can to finish the PCB.

Posted on

Alvin’s Status Report for 4/20

Personal tasks of this week:

Task: Verifying the SLP solver

Definition: Although the SLP solver seems to be running correctly based on its simulation gif, we still need to verify its correctness by comparing it against other solvers. In addition, it needs to be tested against noise.

Completion: I compared results of the SLP solver with an IPOPT solver, and both gave the same results, verifying that the SLP solver is correct. I also tested the solver with an added gaussian noise to theta, and it was still able to solve the problem, indicating that it is robust to some noise.

 

The above gif shows the system with added noise.

 

Task: Setting up the Raspi-PCB interface

Definition: To communicate between the raspi and the PCB, an interface is needed. Namely, the raspi needs to be able to configure the PCB by controlling switches and digipots on the board, as well as give an input voltage and read an output voltage. Performing these operations will require establishing communication protocols using I2C, SPI, and GPIO.

Completion: I was able to find a library that contained drivers for I2C, SPI, and GPIO communication for the raspi. I successfully created an interface for writing from the raspi using SPI.

 

New Tools/Knowledge Learned:

Throughout this project, I learned a lot about the mathematical theory behind model predictive control, sequential quadratic programming, and sequential linear programming. This was done though searching for articles/papers online, and through discussions with Thomas. I also learned a lot about the Casadi library, and how to use it to formulate mathematical problems and real world simulations.

 

Next Steps:

Create the remaining interface, including reading using SPI, read/write using I2C and GPIO.

 

Overall progress assessment:

The remaining work is on finishing the interface and testing the whole system once the PCB arrives. Slightly behind schedule as the PCB has not yet been shipped.

Posted on

Alvin’s Status Report for 4/6

Personal tasks of this week:

Task: Tuning the SLP parameters

Definition: The SLP solver includes multiple tunable parameters, including the bounds for the constraints and the time discretization. The damping coefficient is another variable that is adjustable. Tuning these parameters will effect the performance of the solver.

Completion: Apart from affecting the performance of the solver, these parameters also affect the stability/reliability of the circuit. After testing with different numbers, we found that using the (-0.6, 0.6) as the bounds for the state and (-0.2, 0.2) as the bounds for the control input yielded good results.

 

Note that the pendulum takes multiple swings back and forth before being swung up due to a cost penalty on the control effort.

 

 

Next Steps:

Set up raspi and the drivers for communicating with the PCB.

 

Verification & Validation:

As the digital SLP solver is completed, we can now perform tests to gauge its robustness. Namely, we can run the test suite T2 as we defined in our report.

Run digital implementation 30 times and verify it solves the problem at least 90% of the time

We will run the test with three different starting positions to verify the correctness of the solver.

 

Overall progress assessment:

The SLP solver is mostly completed, moving on to configuring the raspi. On schedule.

Posted on

Alvin’s Status Report for 3/30

Personal tasks of this week:

Task: Deriving the SLP(sequential linear programming) formulation of a dampened pendulum

Definition: Due to the discovery of the limitation in Sergey’s circuit design, we are switching the problem and algorithm to try to accommodate. Thus, I am currently working on formulating the SLP for swinging up a single dampened pendulum.

Completion: The formulation has been derived. However, the parameters for the constraint bounds and the timestep still need to be tuned as SLP is more sensitive to these parameter values. Currently the solver can swing up the pendulum.

 

 

 

Next Steps:

Tune parameters for SLP solver.

Overall progress assessment:

Schedule changed, on schedule.

Posted on

Team Status Report for March 23

Significant risks and risk management:

Risk: The analog circuit as described by Sergey’s Thesis cannot be realized.

Definition: Through some more research and implementing his circuits through simulation, we were able to determine that the constraint primitives are not able to be realized for our optimization problem. Specifically, for the equality constraint, the theoretical formulation assumed infinite op amp rail voltages and the quadratic costs  could not properly be realized without first solving a linear programming problem.

Severity: The severity is very high. If this is not able to be resolved, our circuit will fail to converge.

Resolution:  We were able to resolve both of these issues. For the inequality, we reduced the operating voltage by 10x, so that the maximum voltage that we expect is within the rails of the op amp. As for the costs, we realized that we could not implement these quadratic costs for SQP without first solving a SLP (sequential linear programming), so we decided to compromise and solve our optimization problems using an SLP, using linear costs.

Current progress:

Apart from the risk identified from last week, the current big risk in our project is the uncertainty of whether or not we can create a working solution. We are putting in a lot of work to modify the circuit design so that the circuit is able to perform our needed calculations while remaining within the physical limits of the components, which is something that Sergey did not consider with his design. At the same time, switching from SQP to SLP means that the problem formulations need to be rederived, which will inevitably put us behind schedule. However, we are currently making good progress to both having a workable circuit simulation and a correct SLP formulation.

Changes to the existing design:

Apart from the changes described last week, we have successfully simplified the analog circuit to include less components by exploiting some of the structure within the problem. We also changed the problem we are trying to solve from a double pendulum to a single dampened pendulum to make it less non linear while making it still interesting.

Changes to the project schedule:

There are no significant changes to the project schedule, we are trying to complete the circuit simulation as soon as possible so that we can start to order pcbs.

Posted on

Alvin’s Status Report for 3/23

Personal tasks of this week:

Task: Deriving the SLP(sequential linear programming) formulation of a dampened pendulum

Definition: Due to the discovery of the limitation in Sergey’s circuit design, we are switching the problem and algorithm to try to accommodate. Thus, I am currently working on formulating the SLP for swinging up a single dampened pendulum.

Completion: Currently I am still working on the problem formulation. I had some misunderstandings about the problem structure that hindered my progress, but was cleared after talking with Thomas.

 

 

 

Next Steps:

Complete the formulation of SLP and isolate the LP subroutine.

Overall progress assessment:

Schedule changed, slightly behind but catching up.

Posted on

Alvin’s Status Report for 3/16

Personal tasks of this week:

Task: Changing the simulation time discretization

Definition: Currently, the time discretization for the simulation and the NMPC formulation is the same. Essentially, the next state that the NMPC controller produces is used as the real next state. However, there is a flaw in this design, as the time discretization of the controller is quite large(0.2). This might cause the next state to not actually obey real world physics. To solve this problem, we can change the code such that after the controller produces a control, that is used by the simulator to generate the true next state with a much finer time discretization(0.01)

Completion: I was able to implement this change. The simulation now reflects real world physics much more closely. It also demonstrated that our dynamics derivation and controller design were correct.

 

 

 

Next Steps:

We’ve made some modifications to our schedule and the next step is still to look into ways to formulate the problem in way that is solvable by the circuits we have.

Overall progress assessment:

Schedule is changed, so slightly behind.

Posted on

Alvin’s Status Report for 3/2

Personal tasks of this week:

Task: Formulation of NLP

Definition: Formulating the non linear program for the double pendulum swing up

Completion: After working with Thomas, I was able to derive the NLP for the double pendulum swing up. This consisted of defining the cost function and translating the dynamics of the system into constraints.

 

 

Task: Design review report

Definition: Writing the design review report

Completion: The report is completed.

 

Next Steps:

We’ve made some modifications to our schedule, including adding more prototypes and changing our approach to the problem due to finding some limitations in Sergey’s circuit design, so the next step will be to look into ways to formulate the problem in way that is solvable by the circuits we have.

Overall progress assessment:

Schedule is changed, but still on schedule.