systemetric / robot

🤖 Robocon robot API library for Raspberry Pi and Pi Cam

robot

Robocon robot API library for Raspberry Pi and Pi Cam, developed for RoboCon and the brainbox that is provided along side RoboCon.

This project was forked from the sr.robot libarry see sr.robot

More documentation of how to use this libarry.

robot's Issues

Round end does not always stop robots

The robot in question has a couple of rare modifications:

• USB camera
• Running code after initialization but before the button press

These may be good starting points to test

Tidy up the USB vision documentation

Can robot.res be removed

This is not documented and becomes wrong if changed after robot.__init__

Add FlakeHell to CI run

We should have complete CI coverage for this module to so we at least know it runs and make it vaguely readable.

• Copy action from systemetric/shepherd#32
• Generate FlakeHell baseline for this repo
• Check that it fails if a syntax error is introduced

Enable the end users to disable sections of the postprocessor which they aren't using

Currently there is no way to disable things like writing the image to shepherd

Extra marker properties

AS A robocon competitor
I WANT to be able to easily find my own markers
SO THAT I get to do the fun of having strategy
DONE IS:

• Marker list is returned sorted by distance
• marker.mine returns true for when a marker is a relivent marker.
• The type implmented as follows: https://discord.com/channels/466677345919434793/1029153440254939247/1030877646868983879
• Docs updated

GreenGiant bug workaround

Some missing break statements in the green giant code mean that configuring GPIO will also configure higher numbered GPIO.

The obvious FAQ workaround is to ask users to put inputs on the low numbered GPIO and outputs on the higher ones, then simply configure the GPIO in order.

In robot we could configure all GPIO in order whenever there is a configuration change to any GPIO. Its a little ugly but we can't patch GreenGiants that are in the wild

Cytron waiting in __init__

Is this line really needed?

Get rid of `marker.info`

I think that we should get rid of marker.info and just return the marker info everything as a top level.

General tidy up would be good remove marker specicies.

Should `R.zone == marker.zone`

Currently we make the teams do maths to work out weather markers are ones which they care about.

Filtering the list of returned markers seems to be something which is a challenge for GCSE teams. This is kind of us just having a dumb interface. If the game for a given year has the concept of "their markers" I believe that being able to write code like this would be a good idea:

if marker.zone == R.zone:
     drive_to_marker(marker)

This would also let us clear up this hack in _draw_bounding_box to make the teams own markers thicker:

robot/robot/vision.py

Line 388 in cc98b73

marker_zone = int((marker_code-100)-5/10)

Not sure if this is doing the teams job for them

AT sometimes outputs `Error, more than one new minimum found.`

This is caused when AprilTags solution solving isn't able to work something out. It outputs directly to stderr: https://github.com/AprilRobotics/apriltag/blob/04c4ec3fbb9cbbec1344049323d24e752f01bf38/apriltag_pose.c#L441

I would suggest if the robot logging level is above logging.DEBUG then redirecting the stderr of apriltags to null.

Maybe something like this: https://stackoverflow.com/a/52442331/5006710

Add bounding box thickness to LUT

Currently the bounding box thickness is calcualted from the markers at run time.

This is a hack we are going to for get about it. This issue is for someone to read when we have forgotten about it.