I'm new to Visual Studio and C#, but it seems to me like we only need a single .sln file for the entire repository, since solutions are supposed to be containers for projects, and projects are supposed to be independent executables. Each of the subsections can have a C# project possibly containing other C# projects, but it seems unnecessary to have an sln for every subsection. Thoughts?

Add documentation to BaseStation projects. If you worked on or created one of the BaseStation subprojects, add a readme.md file to its directory or add a section for it in the BaseStation README.md.

Enhance to connect to device based on selection from drop down menu.

There are multiple App.config files in EntryPoint and UserInterface and possibly other folders. The lowercase ones need to be deleted. Perhaps they can both be deleted?

Cake sounds decent: https://cakebuild.net/
MSBuild: https://github.com/Microsoft/msbuild

I guess Visual Studio already uses MSBuild, so that's probably what we should be using.

Random garbage empty tags are put into the settings.xml file when the UI is closed.

So far we have no standard namespace rule for all of the subsystem projects. Here is info on recommended naming conventions: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces. I think HuskyRobotics.[Subsystem] should work fine as a general rule.

Can be reproduced by the following program.

Client side:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Scarlet.Communications;
using Scarlet.Utilities;

namespace ConsoleAppClient
{
    class Program
    {
        static void Main(string[] args)
        {
            Client.Start("127.0.0.1", 2000, 2001, "MyClient");
            System.Threading.Thread.Sleep(3000);
            for (int i = 0; i < 20; i++)
            {
                Packet MyPack = new Packet(new Message(0xc3, UtilData.ToBytes("Hello, World!")), false);
                Client.Send(MyPack);
                //System.Threading.Thread.Sleep(500);
            }
        }
    }
}

Server side:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Scarlet.Communications;
using Scarlet.Utilities;

class Program
{
    static void Main(string[] args)
    {
        Server.Start(2000, 2001);
        Parse.SetParseHandler(0xc3, ReceiveMessage);
    }

    static void ReceiveMessage(Message message)
    {
        Console.WriteLine("Got message");
        Console.WriteLine(UtilData.ToString(message.Payload));
    }
}

Stack trace:

Unhandled Exception: System.ArgumentNullException: Value cannot be null.
Parameter name: str
at System.String.Copy(String str)
at Scarlet.Communications.Packet.Clone()
at Scarlet.Communications.Client.SendPackets()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

Problem:

Communications.Packet.Clone fails to copy Endpoint when it is null.

Possible solution:

Change Clone.Endpoint = string.Copy(this.Endpoint); to Clone.Endpoint = this.Endpoint? string.Copy(this.Endpoint) : null;

Is there a common shared library for utilities that all of the subprojects use (Arm, autonomous, etc.)? It seems like some info on the project structure should be added to the readme.

Either consolidate this solution for the visualizer into the BaseStation solution, or automate the build with pre-build commands in the BaseStation project.

Title. The rover's position icon is visible in the UI even when the UI has received no GPS data.

Weird snapping when you move your mouse around and select a different place, more visible when you move your mouse diagonally.

Refactor UI code and write unit tests for parts. Consider automation testing for view portion.

C# not C++ if possible, due to easier access to a C# binding of some gstreamer features.

Constant Exception thrown: 'System.InvalidOperationException' in System.dll being produced. Is this something internal to the VM or is it something in our program that is being ignored?

Could we please implement a toggle button in the main GUI that simply disables the drive motors while it is enabled? I'd appreciate having it there to try and prevent any accidents from happening while the science station is drilling into the ground, because if someone hits a controller accidentally during that, we're going to have a really bad time.

BaseStation Project > StartBaseStation.cs
Update loop requires > 100 ms thread sleep otherwise UI locks up and must be force killed.

Title

They don't start on the BaseStation computer! Appears to work on other computers.

Support for MJPEG encoding (UI and server), fallback in UI for command line Gstreamer. Notifications for why UI failed to connect.

After competition.

Right now we use 3 libraries for the same purpose; to get controller input. We should work on consolidating to one library.

What is the purpose of having a nested project inside the UI csproject?