usc-auv-team / simulator Goto Github PK

Feature Information

Would read from the RigidbodyManager class in order to collect information and present it to the screen in some kind of on-screen element or portable debug window. Since RBM has getters for its fields, this class would simply focus on the visual aspect of displaying the data

Feature Information

The simulator should be able to receive motor controls (and move the simulated sub accordingly) via ROS while on autonomous mode and should be able to broadcast motor controls to the actual sub while on directed mode.

Solution Information

Modify the SubMovement class to use the ROSConnector class to listen to messages on some channel and respond accordingly. Also use this class to broadcast simulator inputs while on directed mode.

Solution Information

Implement the methods needed to update the following fields.

    private Vector3 acceleration { get; }
    private Vector3 velocity { get; }
    private Vector3 position { get; }

    private Vector3 angularAcceleration { get; }
    private Vector3 angularVelocity { get; }
    private Vector3 rotation { get; }

    private Vector3 displacement { get; }
    private float distance { get; }
    private float depth { get; }

    private float timeElapsed { get; }

Feature Information

Currently input methods have their own classes but these could be abstracted.

Solution Information

Create an InputManager abstract class from which different input methods could derive their managers from. For example, the keyboard import code in the SubMovement class could be moved to its own class.
Controller input is also needed, so this would prevent the SubMovement class from getting cluttered.

Feature Information

As of now, the camera does not collide and with any objects and simply passes through them, which while okay does not really look good. This can be fixed by preventing the camera from clipping through certain objects (ie the walls and floors but not the water) in one of two ways described below.

Solution Information

Either give the camera a collider object so that chosen objects with their own special camera collider can prevent the it from passing through (letting Unity handle collision) but this would mean more overhead for geometry objects and possibly weird fixes as the physics system handles rotation of objects in a strange way.

Or create a script that's in charge of keeping the camera contained within a certain area, basically taking collision calculation away from Unity and letting the script handle putting the camera in a certain place every time it is about to clip something. (Specifically lerping the camera to prevent jittery movements, but this would increase input lag.)

Feature Information

There are some instances where the camera is being modified incorrectly. Creating a debugging environment to really test out the camera and make sure it works with multiple cases.

Solution Information

Additional context

Feature Information

As of now, RigidbodyManager has a public method AddRelativeForce() that allows other classes to add a force to the sub (rather than affecting the Rigidbody component itself, it instead goes through RigidbodyManager.) The Rigidbody uses the box collider in the Hitbox game object, which makes adding forces really simple as they're all affecting the center of mass of the hitbox.

A new feature would be to create individual motors that apply their own forces and take into account the center of mass for changes in angular velocity. That way, the realism of motors applying forces to the overall structure can better portray what would happen with the real sub (i.e. if 2 motors on one side are one and the other 2 are off, then the sub would likely be tilting and going up, depending on the forces and center of mass.)

Solution Information

Most likely RigidbodyManager would have to be changed to account for individual motors in order to apply the forces correctly, as the interface right now is too simple. Feel free to change how it's implemented but remember that RigidbodyManager's purpose is to centralize force input from other classes in order to directly manage the Rigidbody component on the sub.

Size of turtle object is too large (too much detail on the model). Needs to be reduced to make downloading easier and we use less memory.

Feature Information

The current state of the UI is very simple and has little functionality. What would be needed is something that accommodates future features and looks much more cleaner and with better design aesthetic.

What to include

• Persistence of data in field forms
• Interaction with motors (enabled, power, etc.)
• Interaction with ROS Components (enabled)
• Mode switching (automatic, manual, controller)

Solution Information

A mock-up of a redesign will be created that includes the above features. Most functionality will be contained in the HUDManager game object along with small scripts that support additional improvements.

For the time being, keeping every UI element 2D is easiest, but having 3D interactions would be really cool.

Other Information

Here's an examples of having a 3D interaction (a pop-up element) where, in our example, highlighting over a motor would bring up the pop-up and modify it.

Feature Information

In order to better mimic a realistic simulation of an AUV underwater, a buoyancy force is going to be needed as well as a gravity force so that the sub mechanism of correctly aligning itself and keeping its position can be simulated. As of writing, gravity is not being applied to the sub and the water volume its contained with has no effect as well.

Solution Information

There's varying methods of detail to implement such a feature, and at least for now just creating a basic working version would be all that's necessary.

Create a class (contained within RigidbodyManager) that is in charge of applying gravity and buoyancy, as well as a basic version of drag based on the direction and orientation of the sub (more surface area means more drag). This would mean disabling Rigidbody.drag as now this new class would be in charge of it.

Additional context

Here's a Khan Academy article explaining the basics of buoyancy which would be interesting to implement considering it involves surface area and water pressure.

A Unity forum post talking about drag and the issues it can bring up considering it's just a property you set and are unaware of how its implemented.

Feature Information

Add controller support to be able to control the sub with. Not sure if there are specific implementations required between different controllers, but most likely Unity offers an abstraction to not have to worry about.

Feature Information

If the sub needed to realign its rotation back to neutral, then a button (say R) would cause the sub to rotate back to its starting rotation.

If the sub needed to stay in place, then holding a button (say F) would cause the sub to "brake" for every direction and try to prevent any motion, including those by the user. Letting go will disengage the brakes and allow the sub to freely move again.

Solution Information

Leaving input related actions to be taken in SubMovement but physics implementations to be in RigidbodyManager, that way there's a clear distinction between who handles input and who handles physics. To bridge the two, just create methods in RBM to be called by SubMovement.

Description Of Bug

The ROSConnector class won't publish a confirmation message when it connects. It seems to be blocked by the UpdateStatus function.

Expected Behavior

On connection the string "Connected to ROS!" should be published on the topic "/unity".

Additional context

The application does connect to ROS and subsequent messages are sent.

Feature Information

The current GUI doesn't seem to have a system for focusing windows to prevent unwanted inputs from affecting other aspects of the simulations. This was discovered by opening up the settings menu and using WASD to move the sub, which intuitively shouldn't happen since you want the focus to be on the settings menu.

For the future, this is especially relevant if other systems are created (more than just control the sub with keyboard inputs and type stuff into the one field of the settings menu.)

Solution Information

Either Unity already has some kind of focus system that just needs to be researched or one needs to be created. Most likely a focus manager that somehow keeps track of what is allowed to be affected by inputs (keyboard and mouse).

The issue is that other aspects of the sim shouldn't have to be affected internally (ie having a "isFocused" method needing to be called everywhere as that's too much coupling) yet somehow the manager needs to allows inputs to flow through itself and filtered out to other game objects that require it.

Feature Information

There's two underwater effects in place: distortion and fog. Distortion looks really good as it's sort of subtle and looks pleasant, but fog is very broken and only works at the very bottom of the pool. A better method of showing the blueness in water is needed.

Solution Information

A shader that creates a fog-like look to the scene when underwater.

Or a workaround that just make everything look blue while underwater.

Additional context

Best case would making this look like Subnautica because they did it so well.

This is what a normal indoor pool like.

Feature Information

With a camera on the front of sub, this can begin the process of being able to test the computer vision and therefore the navigation system of the sub in order to simulate completing obstacles (e.g. identifying a gate and going under it). However, the first iteration of this feature would not rely on requiring computer vision. It'd be easier to simply allow the sub to keep track of what obstacles are in frame to navigate around (basically doing the identification process for the sub).

As an additional feature, being able to switch between the third person and first person perspective.

Description Of Bug

The ROS connection status indicator doesn't instantly change color on connection. It only changes when the application is removed and brought back to the foreground.

Expected Behavior

On connection, the color of the status indicator should change from yellow to green.

Additional context

This testing was done in Unity.
The color changing seems to be related to #21 since when removed, that bug is solved.