Coming from these comments:

• #38 (comment)
• #38 (comment)
• #38 (comment)
• #38 (comment)

Must Do:

• Rewrite the shepherd API using FastAPI (https://fastapi.tiangolo.com/)
  • This has been attempted elsewhere: https://github.com/systemetric/shepherd-fast
• Add unit tests

Might Do:

• Automagically generate mock-shepherd from shepherd
• Rewrite robot lib
  • Encapsulated within shepherd so that the robot lib outlives the usercode.
  • As a module
  • Possibly in rust

in debug mode, should default to continious execution. Current verbage is confusing, the checkbox should be "Timed Run" and default to off(not timed).

It's reasonably difficult to make sure that shepherd always works from a CI perspective,we have raspi only dependencies but no raspi runner.

The pylint checks at the moment are silenced as we have so many warnings.

Adding flakehell would let us maintain at least a baseline for not introducing any more code which doesn't pass pylint and other static analysis tools.

This would let us check that our python code should in theory at least run.

The logs overflow over the top of the shepherd image this is almost certainly introduced by the CSS change in #25

It could well be that this issue only exists on the brain I have since it hasn't been patched using Will's USB since the week before the launch, but Edwin recommended I post an issue just in case. I have copied the latest versions of shepherd and the robot lib across to the box, but it's possible that I've missed any extra steps

I have noticed that the LED on my brain remains solid (not flashing, which I thought it was meant to) but it can run Robot-less code like

for i in range(5):
    print(i)

just fine.

Running the following code via sheep results in shepherd hanging(?) during the Robot init

(note it never reaches the pre-see print)
The LED doesn't appear to turn off, but it restarts the pi's wireless access point and shepherd. Journalctl doesn't seem to have anything interesting in - just the python language server restarting - but I will attach it here anyway

pi-shepherd-bug-journal.txt

... but again, it could be that this brain is missing some updates

This would allow for a rudimentary version of version control/backups.

Let other people use different editors might be a nice thing for advanced teams. We could have a CLI.

sheep run zips the current folder and sends it to shepherd, assumes that the user defines the entry point in main.py.

Cleaning up the API might be desirable to do first #39

@cupit-dev did start the development of this in 2017 however I think at this point it has been lost to the mists of time.

Not a priority for the target market of robocon though.

Cleaning up shepherd to provide an API which is meant to be used by machines.

The way shepherd is currently used is as sheep which is a hack which is pretending to be a user using the old run and upload pages which no longer exist.

The issue with doing this is the shepherd code whilst is hack is quite battle tested and we can be certain it works.

It is a huge amount of work, the payoff is however much clean code is worth.

Blockley "see" needs to be updated for apriltags as the API has changed.

Noticed too late for Launch, as it needed rebuilding and testing so Brain 1-9 have already left the building.

Hopefully we can patch the others for where students getting started won't have the benefit of our guidance with Python.

Uploading code and then trying to run it causes the "your code seems to have crashed" message. Running the code already on the robot works fine.

Brief

As a Shepherd patch developer.
I would like the docs to be automatically updated from the website whenever the website changes.
So that

• I don't have to remember to update them
• We know that nothing has changed since they were last updated to make them not updatable

Notes

Whenever the docs are changed in the website repo they should trigger some kind of GitHub Action build step which should push an updated version to master of shepherd.

We should be careful about pushing large amounts of binary data to shepherd e.g. images. I already make sure to always clone with --depth 1.

This would let users easily check what their robot can see.

We should replace the image with a placeholder when Shepherd is started, so that people aren't confused by there being an image visible before their code runs.

The logs in sheep once upon a time autoscrolled to the bottom. This doesn't seem to be working at the moment.

We could do with a backup button that backs up all the code in the robot as a download, rather than having to download each file on its own

In #15 difficultly was caused in rebuilding sheep due to changes in the package-lock.json we should always know that sheep builds on every commit to master.

To ensure that people only commit building sheep to master it should be done in CI through GH actions or something.

This would allow users to see what their robots were doing in a situation where the web UI was inaccessible, e.g. in the competition.

Shepherd is a private repo as we have font awesome keys in the repo for the icons in sheep.

I am no designer but there are free icons available online which look pretty good. We should use them instead.

The memes are True. A large part of independent problem solving in the 21st centry especially with programming is being able to google effectively. The current system design stops this self lead exploration.

It also puts more resistance to individuals contacting us through the forum.

Therefore the users machine should be able to remain connected to the internet.

The following properties of our system: are good (though maybe some are obsolete now that we ship laptops?)

• Can work in the locked down enviroment of a school. It should not require any schools IT department to do anything to support the system
• Can work on any machine. Students have a wide range of devices with different archetectures and different operating systems, from chrome OS to windows.
• Wireless. Being able to stay at the laptop whilst debugging makes the experience so much better.
• Can send logs and images back.
• Requires no software to be installed on the users machine
• Works with hardware which we can expect to be in every laptop
• Does not expose the unpatched pi to the internet in a way where we have to worry about security updates
• Can support multiple users reading (but not writing) concurrently

Would be nice to haves in a new system:

• The users machine can use the web through a browser at the sametime
• Software updates to the brain with minimal user interaction.

This thread is to hash out ideas for potential solutions

Downloading the file each time is a good backup but is messy and anoying for the users.

The filesystem API can be used to write directly into the users file system
https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

This is better than local-in-browser storage because it means the backup will be persistant even if the user clears their browser data.

We can use this to ask for filesystem permisions from the user and then we can write directly into their file system and take backups of their code that way.

#43 probally still wants to be done by downloading a zip/

The preview does freeze. I'm fairly sure that it is a problem with the file being written to as it is read which means that the function throws an error which isn't caught and so stops. The bellow was observed in the console when the preiw broke. This should be fixed.

Shepherd uses the raspberry pi GPIO pins and the raspberry pi camera, which means that it can't run without a raspberry pi.

The package fake-rpi is in the dev-dependencies on poetry, but is unused when running sudo python3 app.py; there is not a module to emulate the raspberry pi's camera.

What needs to be done:

• We need to use the fake-rpi module (or similar) to let the script run
• We need to only use the fake-rpi module when we're running on a raspberry pi (could we use the presence of the Rpi module to inform this?)
• It would be good to create a way to fake the raspberry pi's camera interface (perhaps returning static images or similar?)

This is caused by time_left being None when the reaper is disabled.

On a laptop screen the log window can sometimes be quite hard to read.

It would be nice to be able to pop the logs out into a seperate window which took the full width

Currently we test that sheep builds upon every commit. We do not check that the user has updated the build in the repo.

We could either build sheep upon every commit and then commit those changes.

Probally easier to do is if we just diff the build files with the commit ones. This will let us see if anything is out of date then commit an updated build later.

Great improvements in terms of efficiency and features have been made to both monaco and the langauge server. Using these lastest features would allow for better explainations to the users why their code does not work before they have run it. This is highly desirable for RoboCon.

This will likely mean using a more recent version of node, and probally breaking everything.

I hope someone can enjoy this task.

It was observed at robocon 2022 that markers which were out of frame could be detected on the screens therefore the image is shown is a cropped view of what the robot can actually see.

Need to work out where in the pipeline this is happening.

People feel like it's hard to work out how to develop sheep because they don't know how to set up the dev environment.

We should have a script to install:

• Node
• Nvm
• Set the node version to the node version in package.json
• Dependencies

We designed the GreenGiant to only boot when the voltage was good (11v), but not to quit until it gets very low indeed (~9v) at about 95% discharged. This was done so that voltage sag due to large motors wouldn't cause a brownout, but does expect that the battery is well balanced. If the battery has become unbalanced then this can kill the battery. We may have lost a couple of batteries to this in 2022, but the batteries might also have been dying already having not been stored correctly in 2020.

This behavior is all just fine (tm) for regular power cycles, but due to changes in how the robots work, we are no longer seeing these cycles (even when robots arrived in the arena, because the sticks only restart shepherd). In the old world the worst a battey would get is 11v before a round, down to 9v if you pushed it. Now we should expect robots to hit 9v before anyone does anything about the battery.

In this new world we should probably switch to a different blink pattern and refuse to accept start if the battery is less than 10v at R= robot()