snl-waterpower / siweed Goto Github PK

@nickross4444 @delaneyheileman @DeepFriedDerp - I have updated the README with 589ed40 to include a section about contributing. I'd like to follow the gitflow workflow. Although we do not have deployed code/active users at this stage, we will eventually be running this code on hardware and making changes to both the hardware and software, likely in parallel. @gbacelli and @dforbush2 can tell you stories about the potential havoc that this can create. As such, having a master branch that is stable can be quite useful for safety and reliability.

@nickross4444 - Can you please add section(s) to the README that explain how to get started and list necessary dependencies that are not included with the repo? I particular, this should help someone like me, who hasn't run the GUI in a while, get everything connected and running.

I was going to put this as a comment for #38 but I think this might be a bigger bug? I am not sure, to be honest.
I am seeing a weird usage pattern for the GUI on my desktop.
When I launch the GUI, it takes maybe 5 seconds, the CPU usage is 35%, memory usage is 1Gb and GPU usage is pretty much 0%.
The weird part, which I am not sure if it's a memory leak or what is that after a few minutes the memory usage starts to climb (without even touching the GUI). At the same time, Dedicated GPU memory usage starts to go up to 99%.
Then after like 3 minutes, the GPU usage starts climbing?
So after like 5 minutes, the GUI is pulling ~30% CPU, ~7Gb Ram, 3.8Gb GPU memory, and ~70% GPU usage (under task manager it says its "copy" whatever that means).
The following images are 3-4 minutes after launching the GUI.

Since Arduino does not natively implement the c++ stl library, we are using a community one for vectors in the jonswap library. It does not compile on the DUE, and is fairly old. I think we should update to a new stl library.

By combining the techniques from the unit tests and the changes in c24ac47, it should be possible to get processing to auto select Arduinos, making configuration much easier.

The phase in the arduino Jonswap library is assigned with a defined seed for random number generation(123). This produces different results on the Due and on the Mega, likely because the different chip architecture(ARM vs Atmel).

• Buttons and sliders should be a min of 20mm (~75 pixels)
• Should be made so that most of the left hand side is taken up by controls so it looks right aesthetically

FFT graph needs to be move down

@DeepFriedDerp - I've sent you an email with a link to access the photos and videos I've taken thus far. Please work with Carolee to take some more. I would suggest getting shots of every single component showing the model number.

Generally the Github site is not a great place to keep these, since Github doesn't like to store large files. We can set up an internal sharing site at Sandia, but maybe you can just hold onto them for the time being.

Jonswap Java Class is here:
https://github.com/SNL-WaterPower/siweed/blob/master/Processing/siWeedGUI/miniWaveTankJonswap.java

The processing sketch is designed to give the jonswap these inputs:

• sigH
• peakF
• gamma

and these output vectors:

• amplitude
• phase
• frequency

the size of those arrays will have to be an output or a constant.

As the component count gets above 50, the variation becomes significant. Testing can be done with the example program in the jonswap library on the Arduino and the testing block on line 52 here.

Right now the background color of the power meter is white. Ideally it should be the same shade of blue as the buttons. Maybe this is something you can play with @SeanPluemer

GUI seems to take a very long time to load and has a low refresh rate. Don't know if the demo PC has this problem(@delaneyheileman can comment on this). Possible culprits and improvements:

• Serial auto connect takes up to two seconds per usb device connected. The time it takes for unit tests to start printing is mostly this connection time.
• Larger functions like serial interpretation can be handled in threads. This should be fairly simple.

currently, you need to click twice to make anything happen with the touch screen GUI

The labeling system by default is not very... Helpful?
I would like to revamp the labeling system to allow us to be more intuitive.

As you can see from the above picture, there is a status, type, and priority label. Each of these labels will have sub-labels (Ex: High, Medium, Low priority) This will allow us to be able to quickly view what the progress is for each issue.

When you select click a button (button1) it changes color, when another button is pressed(button2) it also changes color but the button1 does not revert to its original color. When a third button(button3) is pressed the button1 reverts to the original color and button2 and button3 are the same color.

Update the layout of GUI to match photo

It's come to light that the power meter library is causing a number of serious issues, including the font errors and most of the optimization issues. We've decided to get rid of it, and I plan on making a new one with the original graphics. My current plan is to use 2 png's for the background and needle, so it won't be as flexible, but I think that's worth it. @delaneyheileman could you tell me what colors we want the meter background, text, and needle to be, and what the range should be as well?

How does the Gitflow workflow work for the ReadMe? We have issues pointing to the updated ReadMe but linking to the master Readme (which has not been updated).
If we update the master readme, the guidelines will not be accurate as there are changes in the debug that are not live yet.

added on screen console that will show the user the type of communication occurring. Using the console library.

Here are the update rates on various systems as of today (4/20).

• Processing: 30 Hz
• Wave maker Arduino (Mega)
  • General: 100 Hz
  • Serial communication: 30 Hz
• WEC Arduino (Due)
  • General: 100 Hz
  • Serial communication: 30 Hz

Here is a screen shot of the current GUI. Please give your input!

We will want to log the following signals to a CSV file (probably forgetting something and will need to add to this list).

• mode_wec
• kP
• kD
• pos_wec
• tau_commanded
• pow
• mode_waveMaker
• Hm0
• Tp
• gamma
• pos_waveMaker

This is underway with 427dc56

Here is where I got the FFT function. It looks like they recombine the imaginary and real parts in to a normalized array near the end.
https://discourse.processing.org/t/fft-of-1d-array-of-1024-measurements/7901/16
This was my result after graphing that array directly:

His implementation is a bit different because he generates his own signal, but mine in similar in that it passes an empty imaginary array. Let me know of you need to see my specific implementation.

I guess what needs to be answered is what data are we trying to graph and how does it need to be manipulated before plotting?

need to be able to click anywhere and have pop up disappear. currently only appears / disappears when clicking on '?'

Can be reduced by configuring the Wave Probe to not use RS232 communications. Can also be improved with a filter in processing.

Please update the systemLayout diagram (https://github.com/SNL-WaterPower/siweed/blob/master/documentation/diagrams/systemLayout.pdf and https://github.com/SNL-WaterPower/siweed/blob/master/documentation/diagrams/systemLayoutPNG.png):

• WEC Motor
• WEC controller
• WEC encoder
• WEC Encoder decoder?
• PWM ICs for wave maker per #26
• Make subsystem box around wave maker components

Documentation for the board:
MAX14890E.pdf
MAX14890EEVKIT.pdf
Encoder:
amt10.pdf

Trying to figure out how to wire the encoder and Arduino to the board.

All,

I have created a list of 2020 weekly milestones, tied to each Tuesday (our weekly meetings).

On the right-hand side of each issue, you can select to tie each assignment to a milestone.

This will give you a due date (included in the milestone name), and will allow us to see which issues are holding up the completion status of a particular milestone, thus enabling tracking of due dates and an accountability model for work assignments.

Changes to an issue's milestone will be logged in the issue itself, so we can also track the number of due date extensions.

Please note that this is not to micromanage, but merely a way of keeping track of things, for any people on the team who benefit from having due dates and extension metrics.

@delaneyheileman, @nickross4444 @SeanPluemer, please go through and assign reasonable due dates to each of your actions that should have a due date before the end of the year. These due dates are just estimates, and we can extend them if necessary.

Per the conversation at our last meeting, this will be due by next Tuesday's meeting, which will be reflected in this issue's milestone info.

I will be researching how to make the Signal Generator (Sparkfun 11420) generate the wanted signals.
Right now, the Sparkfun documentation is not very good and further research is needed.

Not sure if "bug" is the correct label, but since the description is "Something isn't working" feels pretty accurate.

Change text box that explains GUI from regular text boxes to ControlP5 textarea for easier control

due: 2019-09-20

I will be using this issue for testing due date automation.
Please ignore

Here is a limited explanation of how the unit tests work:

FFT: Fills the FFT buffer with a sin wave, calculates the FFT, and compares the resulting array against a pre-defined one.
Serial: Calls the readSerial() function, which sets a flag true if it receives the expected variable. Different variables are used on the Due and Mega.
Jonswap: In setup, the Arduinos calculate the jonswap and time series with defined inputs, and compare the amplitude arrays and samples of of the time series to pre-defined arrays. If the tests pass, a flag is set. When requested from Processing(in setup), the flags are sent with their own label.

@4MANN444 - Can you provide a diagram of the current serial communication system?

EDIT: and any websites that discuss your approach

While researching on the optimization stuff I have come across a couple of cool ways people have made their program dynamic in the shape.
It might something as easy as doing frame.setResizable(true); and rather than putting everything at a xy location put them at an xy anchor. If I have time, I will look into this. I don't think it will be too hard to do, just a bit of trial and error.

Based on last week's meeting I think it would be a good idea to create a diagram to visualize how the code works.
I met with Nick for 20 minutes and simply having him explain the code out loud helped him realize a few things that could be changed. This will also be a good exercise to help me understand how the code works as a whole.
I suggest this as being a mid to long-term milestone, as it isn't very high up on the priority list right now.
Without starting, I have a general idea of the diagram is like the below picture.

due: 2020-10-28

Whenever the GUI launches I get a few "font is not available" errors. I will work at fixing this, should be fairly easy.
Also, side note... what is the "The sketch has been automatically resized to fit the screen resolution"? @delaneyheileman Any ideas, since I thought the GUI was a static size... Will look into it.

As mentioned in #29, prior to making the repo public we will need to apply for a copyright assertion. We should allow ~2 months for this to go through.

change slider and button text - need to research this in the controlP5 library. Will do after more things are placed.

@ryancoe Select a license

I've added a simply MATLAB script w/ bb2e1dd name wecExample.m. This demonstrates the four modes of operation. They are generally quite simple.

The only one that is not straightforward or a replicate of previous work is the feedback controller - even this is not too bad. We are basically

1. Set two control gains (kP and kD) on the GUI
2. pas these gains to Due
3. Due finds position from encoder
4. Due calculates velocity based on current and previous position
5. Due calculates torque (tau) based on the kP and kD gains (this is just a PD controller - a PID controller w/o the I: https://en.wikipedia.org/wiki/PID_controller)
6. Due commands torque to motor controller
7. Due calculates power based on velocity and torque
8. Repeat

Change the size and font used in the GUI

The methods/library we're using to control the stepper motor for the wave maker allows fast motion, but cannot work below a certain limit (2.6 mm/s with our current gearing). This can create jittery behavior, especially in jog mode.

@nickross4444 - Rewrite this if I've misunderstood the problem or left things out

Would be nice if the GUI can run without Arduinos connected.

The four Jonswap Unit tests usually fail. This is most likely because the tests are too strict, or the random seed is not set. Likely a quick fix, but not a near term issue.

There is some non-zero error in the wave maker tracking (order of magnitude: <10mm). This is something that we may want to address eventually... but not critical.