FloatShield: Long term outlook and ideas

[gergelytakacs]

@PeterChmurciak

I will be no attending my usual academic duties as I will be on vacation until the 8th of July (e.g. next week). This post shall give you some long term ideas for possible activities. Mind you, this is not a schedule you shall definitely complete by that time, rather a couple of things that can meaningfully contribute to the development of our efforts. Some may be easy, some not so much. The prime tasks remain with getting a meaningful data stream for identification and tuning the PID controller, speeding up sampling etc. - these are mentioned in other issues and you are aware of them.

• Check out the MATLAB System Identification Toolbox and its tutorials from the MATLAB help. The tutorials are actually quite good and you may learn a lot of useful things. I'd do as much as possible.
• Check out the Simulink Parameter Estimation tool. This is something I have not done before, but I think it should be very useful and want to look at it myself in the future.
• Attempt to formulate a good mathematical model of the dynamics, e.g. FloatShield: First principles model #166 Essentially we want to relate the PWM input (or percentual power input) to the height of the ball. I think the first step to achieve that is to get a good force balance equation.
• Think about a hardware upgrade of the shield. Whether it's just a "facelift" or a more serious re-design is up to you. It begins with stating the goals. One of my issues with the current design is that it's not 3.3V board compatible, such a change would fall into the "facelift" category. You may open a stand-alone issue for this. Look at AutomationShield Hardware Style Guide #19 for a bit more info.
• Try to think of how the sensor could be used in Simulink. This is a though one though. You need to port the API for the device (the TOF) sensor to Simulink. It certainly does not sound fun at all, however, I think it is realistically doable.
• Try to think if and how the sensor could be used in MATLAB. This may be even more though than for Simulink and I'm not completely convinced if it can be done at all.
• Study the HeatShield MATLAB API to see how I implemented functions using the MATLAB object-oriented style and think about how you could do the same to Float. This can only be done of course, if the sensor works.
• Study the HeatShield and OptoShield Simulink API to see how I implemented functions using the library block collection and think about how you could do the same to Float. This can only be done of course, if the sensor works in Simulink.

I think that's plenty to keep you entertained:)

[issue-label-bot]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.61. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[PeterChmurciak]

@gergelytakacs I have been trying to make the laser sensor work in MATLAB and after a lot of complications it seems I was successful. I have managed to create MATLAB add-on from the Pololu sensor library that allows us to read data from distance sensor through MATLAB. There was one similiar add-on available, but it used the Adafruit library - which we have decided to replace because of sampling reasons. The add-on can be currently found in this repository with some instructions on how to use it.

As it is, the add-on relies on the Pololu library that has to be included in Arduino libraries, so for our purposes, it will have to be modified to use Pololu library from submodule. I was not sure what submodule to use because of issues discussed in #168 (comment) so I just uploaded this arduino-library-dependent raw version. I am now going to work on MATLAB API for FloatShield, and will correct the library source when the issue will be resolved.

[gergelytakacs]

@PeterChmurciak This is absolutely wonderful. Very good job with this, I'm really glad you have managed to port the sensor into MATLAB.

As of the Polulu library, please use the submodule that connects to your very own fork, as the Polulu guys seem not to be pulling in changes. Also see here.

When creating the API your reference is the HeatShield, as this is currently the only existing MATLAB interface for heatshield devices. Try to be consistent with the code and ideas there so the library is more or less uniform accross various devices.

[gergelytakacs]

@PeterChmurciak I'd like to know where you stand with the decisions regarding the use of the "linearizer" (I think you kind of said no) and getting a 'final' tuning out of the PID. Are you waiting for some balls you've ordered?

The reason I ask is, that if you are more or less content with the hardware right now (R1) you should try to "finalize" the Arduino IDE part for now and try to pull out some good lookin' test data and PID responses. Something representative...

[PeterChmurciak]

@gergelytakacs I say no to the linearizer. I have tried it some more and it did not provide consistently better results for me.

The tuning that the FloatShield PID examples currently use is the best I managed to come up with, and I was thinking about using MATLABs system identification toolbox and then some form of PID tuner to see if I can get something better. I am not yet sure if that will be sucessful.

No, I have not found any other balls that would suit our tube. The ones I ordered were either too big or too heavy.

Alright, I will try the mentioned MATLAB part, to see if I can get better PID constants out of it and then try to get some very nice and colorful plots. How do you imagine the responses to look ? I mean should it be for example data recorded in a text file and shown in a MATLAB plot ?

[gergelytakacs]

I say no to the linearizer.

Allright, that's settled then!:)

The tuning that the FloatShield PID examples currently use is the best I managed to come up with, and I was thinking about using MATLABs system identification toolbox and then some form of PID tuner to see if I can get something better. I am not yet sure if that will be sucessful.

Good enough for me then. I found the MATLAB PID Tuner to be not much better than good old hand tuning, but of course, give it a go by all means! Also before that we should probably take identification much-much more seriously to have a good model in the first place. That has been neglected so far. I'd say then, try to pull out some "text" (CSV) results and then we'll process them into something more presentable.

No, I have not found any other balls that would suit our tube. The ones I ordered were either too big or too heavy.

Neither have I. So let's settle it like this: at the current phase of the project, work with what we have, e.g. the old ones. Redesign it more seriously for R2 next, you can change ball/tube sizes etc.

How do you imagine the responses to look ? I mean should it be for example data recorded in a text file and shown in a MATLAB plot ?

Yes, exactly. Dump data as text and log them using a terminal program (e.g. CoolTerm or similar). Then we'll have the freedom to process the data for our specific needs. This can be considered as the "final" result of a particular portion of the FloatShield R1 effort. This data then will be used in a possible future conference paper to present the results and your master's thesis. So data is valuable, take care to sort, understand and store it properly:)

[gergelytakacs]

@PeterChmurciak Not entirely FloatShield specific, but made Travis logs more readable by disabling some junk, e.g. https://travis-ci.org/gergelytakacs/AutomationShield/builds/556807402

[gergelytakacs]

@PeterChmurciak

I will most probably be on vacation the next two weeks, but should be still in the office this week. If you feel like talking to me personally, you are welcome to stop by, just maybe let me know when - so you don't make the trip for nothing. However, I do not require you to visit me as I consider our communication Through this platform going well, it's really up to you.

If you decide not to come, which is fine, I will react to your notes here for this week, then might write you a list of ideas to do for the upcoming time! Just letting you know in time how I plan my schedule.

[PeterChmurciak]

@gergelytakacs Thank you for informing me.

[gergelytakacs]

@PeterChmurciak Can you please post here a screenshot of the PID experiment that you consider as reference? Can you please also post here (just *.zip it) the raw data?

[PeterChmurciak]

@gergelytakacs I think the response from latest Arduino PID example is pretty fine:

The comparison with MATLAB version and raw data can be found in #171 (comment).

What do you think ?

[gergelytakacs]

More than fine, see #171 :)

[gergelytakacs]

Hello @PeterChmurciak

As you know, I will be off to vacation for a week, will be attending my usual duties on the 29th of July the next time. Until then, I'd recommend keeping busy with the following priorities:

1. Simulink API and PID example
   2 . Open-loop data gathering and thinking about first principles identification and the model.

Of course if you are running into trouble with these things (or just simply sick of trying something) here are some alternative things you should do, that will be useful at some point in the future:

• Check out the MATLAB System Identification Toolbox and its tutorials from the MATLAB help. The tutorials are actually quite good and you may learn a lot of useful things about practical system identification and about creating dynamic models of machines and processes. I'd do as much of these as possible to learn.
• Check out the Simulink Parameter Estimation tool. This is something I have not done before, but I think it should be very useful and want to look at it myself in the future... This may be actually useful if we attempt to do a closed loop identification, because, according to my previous experience with the MATLAB SIT, it is quite hard if not impossible to use if for open-loop unstable nonlinear systems. (Tried it with Magneto, failed miserably so far.)
• Attempt to formulate a good mathematical model of the dynamics, e.g. FloatShield: First principles model #166 Essentially we want to relate the PWM input (or percentual power input) to the height of the ball. Now we have a more reasonable idea what should be achieved, but we still have wind speed there. How can we measure and log airspeed? How can we relate PWM input to airspeed?
• Install and learn LaTeX. Your Thesis will be written in this system. Any serious presentation (e.g. conference article etc.) will be also written in this system.
• Try to think of how the sensor could be used in Simulink. This is a though one though. You need to port the API for the device (the TOF) sensor to Simulink. It certainly does not sound fun at all, however, I think it is realistically doable.
• Study the HeatShield and OptoShield Simulink API to see how I implemented functions using the library block collection and think about how you could do the same to Float. This can only be done of course, if the sensor works in Simulink.
• Think about a hardware upgrade of the shield. Whether it's just a "facelift" or a more serious re-design is up to you. It begins with stating the goals. One of my issues with the current design is that it's not 3.3V board compatible, such a change would fall into the "facelift" category. You may open a stand-alone issue for this. Look at AutomationShield Hardware Style Guide #19 for a bit more info.