rursprung / fhgr-mrproj2

A ROS 1 based tank with a LIDAR.
GNU General Public License v3.0
2 stars 2 forks source link

define APIs #21

Closed rursprung closed 1 year ago

rursprung commented 1 year ago

this adds a first draft for how the APIs should look like. most communication will happen with ROS messages, however triggering the gun will be a service call (because it has to happen exactly then).

the speed sensors on the tracks have been removed because they were not accurate enough, accordingly they have also been removed from the diagram.

note that the result of the image processing is a PointStamped rather than just a Point because we'll only want to act on it if the information is recent enough (with messages there's no guarantee on delivery time, though usually they're fast) as otherwise we might already be past that point. maybe this is not needed, but we'll have to see the behaviour once we're implementing it. also, we'll have to define more clearly what the point represents - most likely, it is the centre of the identified QR code. otherwise we'd have to come up with a message format which contains four points to identify the edge points of the QR code, but that'd just be overhead because the controller would then anyway have to calculate the centre to shoot at that (shooting at the centre should give the highest chance to actually hit the target).

as it looks like right now we won't have to implement any custom message types but can instead rely on the standard message types provided by ROS.

still not shown are transformations done by helper functionality, e.g. taking the raw LIDAR data and converting it into a LaserScan. this will just follow the same pattern as in SMB (which we haven't analysed in detail yet but will do while actually implementing it). the same is true for the image processing, which will be analysed in more details in #17 (probably we can rely on the image_pipeline for this).

also currently missing is the definition of how the controller will publish the mapping data. this is mainly because we have no experience with it yet, but this will come later in the semester. as there's no consumer for this information it's also not important to already define it now.

this solves #8

rursprung commented 1 year ago

sorry, just had to rebase so that the CI would run here (wasn't yet part of the baseline of this branch but the CI build is now required for all PRs). no change to the content