Develop Method for Deriving Dynamic Model of the Boat

[arandell93]

Refs #8

I suggest prior to/as part of Rev 1.3 we obtain what we consider to be the appropriate instrumentation and integrate it (if only temporarily) in such a way we can set up a sequence of outputs and record and store the inputs. We can execute this sequence enough times such that we have a representative sample of the boat's performance. I see this as being crucial during our early-Spring testing to keep us on pace for developing a well-tuned control system.

While we need input from everyone to develop a comprehensive test, I am assigning @cgregory52 to be the designer of the experiment to ensure we cover all dynamic states of the boat in a statistically significant way. Further, we need to quantify and control for the testing conditions (wind, wave height, heading with respect to waves/wind, boat payload, distribution of payload, battery charge state, etc.). We also need to come up with an understanding of how we will use the data we collect in the formation of a dynamic model which can be applied to a control system and implemented in software.

Instrumentation Required:

• Inertial Measurement Unit (Particularly Accelerometer and Gyrometer)
• GPS with high update rate (position, velocity, heading)
• System Voltage Measurement (perhaps on each motor as well?)
• Current Measurement on each motor

I propose the following test setup to be used to understand the velocity/acceleration response of the boat:

• A pre-programmed set of thruster outputs to represent a wide range of conditions of the boat. This would need to be done repeatedly in both directions (forward/reverse).
  • Straight line path with slowly increasing throttle for x duration
  • Straight line path at full speed for x duration (reapeated for various throttle levels)
  • Straight line path with slowly decreasing throttle for x duration
  • Stopped to Full Ahead(Astern) to determine acceleration (repeated for various throttle levels)
  • Full Ahead(Astern) to Stopped to determine deceleration (repeated for various throttle levels)
  • Full Ahead(Astern) to Full Astern(Ahead) (repeated for various throttle levels)

I propose the following test setup to be used to understand the heading/yaw rate response of the boat:

• A pre-programmed set of thruster outputs to represent a wide range of conditions of the boat. This would need to be done repeatedly in both directions (turning to port/starboard), each at various speeds and in both forward and reverse.
  • Start with the boat stopped and slowly increase the magnitude of each motor's speed, but have them spin in opposite directions, then slowly bring it back to a stop
  • Start moving straight ahead and slowly decrease the speed of the inside (relative to the turn) motor past stopped until it is at the same magnitude but opposite direction of the outside motor
  • Start moving straight ahead and slowly increase the speed of the outside motor until it is at its maximum speed
  • With the boat stopped, set both motors to speed x but in opposite directions
  • With the boat stopped, set the inside motor to speed x
  • With the boat stopped, set the outside motor to speed x
  • With the boat turning using differential drive at speed x, stop the motors abruptly
  • With the boat turning using the inside motor at speed x, stop the motor abruptly
  • With the boat turning using the outside motor at speed x, stop the motor abruptly
  • Z-turns at speed x
  • S-turns at speed x

I'm sure there are other tests we can think of. Feel free to add them here and to discuss other ways by which we can quantitatively expose the dynamic model of the boat.

[FifoIronton]

Another part of modelling, along with data collection, is using the physics of the situation to make a model of what we think should happen. The world seems way too complex to find a perfect model by just looking at data, but we can compare different mathematically derived models to what we see from our tests.

For example, a lot of differential drive robots that have only two outputs (u_r is the right wheel speed, u_l is the left wheel speed). For the sake of controlling the robot, it's assumed that the robot is controlled exactly as

,

where r is the radius of the wheels and L is the distance between the wheels. Even though we know that in real life the wheels will slip differently on different terrain, maybe one of the motors is a little stronger than the other, and maybe the symmetry of the robot is a little off. However, this model is generally good enough to use for a controller...

Besides the fact that it kind of sucks to work with. So the smart math people of the world create more abstract models for the sake of better control. They do some mathy transformations, and say that the robot can be treated as a point with the characteristics:

This looks a lot more fun to think about, because the inputs are u_s (speed) and u_ω (angular velocity), because with this model your steps to get to the goal are to point the robot to the goal and slow down when you approach it. You can just equate the two formulae to figure out that the actual inputs of the robot are found as u_r = (2u_s + u_ωL)/(2r) and u_L = (2u_s - u_ωL)/(2r).

In our case, we aren't this lucky, but I still think it's useful to abstract our thoughts for controller design. @cgregory52 is going to tear me apart for my low-level understanding of kinematics, and he'll actually have to design the real model, but let's use a point mass model for the boat and say that with our thruster configuration we control forward (u_a) and angular (u_α) acceleration (thrusters make thrust, which I think is a fancy word for force, which I think is a fancy word for acceleration times a constant). Add in the fact that drag is also a force that acts based on the speed through the water squared and we can deem the boat to work with the following (incredibly bad) kinematic model:

Which we can then try to use to design a controller (although it's not exactly linear). After that, we can use our tests and understanding of thrusters to figure out how thruster input can be used to get the acceleration input terms u_a and u_α. Hopefully that will be enough to make a simple go-to-goal controller. It's well understood that our models don't take all of the factors into account, but if they can take the major ones into account hopefully it is good enough for the controller

[arandell93]

Very well thought out on the comparison to differential drive robots. I think we can definitely use this as a starting point for developing a set of equations to use to input into the control system. The constants will surely be a bit of a challenge to derive (and will likely not be constants by the time we have a working control loop) but should we sufficiently understand the physical meaning (and units) of the constants we should be able to pull something out of our data to apply to them.

I note that your proposed equation for the boat is the model for acceleration, whereas the end goal will be a control system for position. I'm not sure I completely understand the impact of this, but looking at your equations for acceleration, there is a dependency on the velocity equation within them (from the drag component) which I think (though I am admittedly pretty rusty) means fancier integration rules come into play.

[arandell93]

I just did a bit more reading and came across the concept of a Braitenberg Vehicle.

It's a short article, have a read through it. If I am understanding it correctly (and it seems relatively simple) I think we could apply this logic to our system to produce a very simple controller for our boat.

[whymarrh]

@cgregory52 @arandell93 @FifoIronton what is the status of this issue?

[arandell93]

Not worth our time. We'll manage through brute-force tuning. Discussion of control algorithm can be moved elsewhere when needed.