Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RSDK-1705] add colormap for SLAM UI #2160

Merged
merged 14 commits into from
Apr 10, 2023
Merged

[RSDK-1705] add colormap for SLAM UI #2160

merged 14 commits into from
Apr 10, 2023

Conversation

JohnN193
Copy link
Member

@JohnN193 JohnN193 commented Apr 4, 2023

This PR is updating the SLAM 2D render to apply a greyscale color map to the pointcloud based on the color attribute's probabilities. The code assumes that colors to range from 0 to 100 in the blue/z channel, and sets the colormap accordingly.

Tested with fake slam and a large offline cartographer dataset on mac, and an offline orbslam dataset on a pi using an appimage and local config.
Screenshot 2023-04-04 at 1 39 56 PM

ticket: https://viam.atlassian.net/browse/RSDK-1705

@viambot viambot added the safe to test This pull request is marked safe to test from a trusted zone label Apr 4, 2023
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 4, 2023
@JohnN193 JohnN193 added the appimage Build AppImage of PR label Apr 5, 2023
@JohnN193 JohnN193 marked this pull request as ready for review April 5, 2023 15:51
@nicksanford
Copy link
Member

AppImages ready! http://packages.viam.com/apps/viam-server/viam-server-pr-2160-x86_64.AppImage http://packages.viam.com/apps/viam-server/viam-server-pr-2160-aarch64.AppImage

This is awesome! I didn't know this github workflow existed!!!

@@ -8,6 +8,36 @@ import { MapControls } from 'three/examples/jsm/controls/OrbitControls';
import { PCDLoader } from 'three/examples/jsm/loaders/PCDLoader';
import type { commonApi } from '@viamrobotics/sdk';
/*
* // Leaving additional color map commented for if we want to change to a different scheme.
* // const colorMapViridis = [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mind adding the url that defined this color map?

* // ]
*/
// this color map is greyscale
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mind adding the url that defined this color map?

@@ -78,6 +108,21 @@ const disposeScene = () => {
scene.clear();
};
// Find the desired color bucket for a given probability. This assumes the probability will be a value from 0 to 100
const probToColorMapBucket = (normProb: number, numBuckets: number): number => {
Copy link
Member

@nicksanford nicksanford Apr 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add unit tests for this function that shows how it behaves with probabilities both within the expected range & outside the expected range and with varied numbers of buckets?

You should be able to follow a similar pattern to what is done here: https://github.com/viamrobotics/rdk/blob/main/web/frontend/tests/unit/Base.spec.ts#L1

I'm happy to pair with you on it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No current unit testing framework is set up yet for RDK, recommend just moving forward without tests until we complete https://viam.atlassian.net/browse/APP-1600

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool stuff, added a ticket for SLAM to make some tests after that one https://viam.atlassian.net/browse/RSDK-2606

* Map the color of a pixel to a color bucket value.
* normProb is the probability value normalized by the size of a byte(255) to be between 0 to 1.
*/
const colorBuckets = (normProb: number): THREE.Vector3 => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this also be unit tested?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added a ticket to unit test this https://viam.atlassian.net/browse/RSDK-2606

if (colors instanceof THREE.BufferAttribute || colors instanceof THREE.InterleavedBufferAttribute) {
for (let i = 0; i < colors.count; i += 1) {
const colorMapPoint = colorBuckets(colors.getZ(i));
colors.setXYZ(i, colorMapPoint.x, colorMapPoint.y, colorMapPoint.z);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@micheal-parks Just confirming: Is this the idiomatic way to set the color scheme of points in three.js?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@micheal-parks do you know why three.js uses setXYZ instead of something like setRGB for colors? Is it because the color type is a more generic THREE.BufferAttribute

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, it's because the BufferAttribute class is used for any all sorts of vector data, like colors, vertices, normals ,etc, and the authors haven't added a setRGB alias function

// if the PCD has a color attribute defined, convert those colors using the colorMap
if (colors instanceof THREE.BufferAttribute || colors instanceof THREE.InterleavedBufferAttribute) {
for (let i = 0; i < colors.count; i += 1) {
const colorMapPoint = colorBuckets(colors.getZ(i));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[q] Why do we get the probability number from Z?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We make the assumption in our current slam implementation that probability will live in the blue channel of the PCD, by setting the color integer to a value from 0 to 100. 100 is less than 255 so only the blue channel needs to be evaluated. The way the color attributes appear to work for three.js is the RGB fields correspond to xyz fields. I did not dive into three.js documentation to see how loader.parse explicitly handles this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused b/c I thought that we put the probability data in the R channel here: https://github.com/viamrobotics/viam-cartographer/pull/25/files#diff-92ff8a5cd3a57430d78c6ba3b61a91d1810399b77613eece3c55841868d2822eR56

@jeremyrhyde @JohnN193 am I missing something?

Copy link
Member Author

@JohnN193 JohnN193 Apr 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yeah, cairo has probability encoded in the R channel, but after we math out the probability value, pass that char into the integer field of the PCD. the integer field(calling it rgb for simplicity) works as follows

int rgb = 0;
rgb = rgb | (red << 16);
rgb = rgb | (green << 8);
rgb = rgb | (blue << 0);
viam::utils::writeIntToBufferInBytes(pcd_data, RGB);

I am not 100% certain how the pcdloader is handling the 4 byte integer, but experimentally this was found to be the Z channel(for cartographer PCDs the other two channels are 0)

Copy link
Member

@nicksanford nicksanford Apr 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Thanks for explaining!!! Would you mind please creating a ticket for the fact that currently the remote-control frontend & any users of slam need to have intimate knowledge of how the specific slam algo implementation encodes probability information the color integer value in the PCD (which currently only works for cartographer) so there is product awareness & we can prioritize when to come back to it to make it more generic / type safe / documented & add a comment at the top of this file with both the assumption this component makes about the PCD color information & a link to the ticket to come back to re assess those assumptions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for explaining!

It sounds like since carto_grpc_server is returning a PCD with format "x y z rgb" and putting a probability value 0-100 in the 'rgb' field. Since 0-100 is guaranteed to be less than 255, the probability will end up in the lowest byte, so we're able to pull it out by looking at the 'b' channel.

Agreed this is pretty roundabout. To consider in RSDK-2605: I wonder if we could use a PCD format "x y z intensity" and store the probability in intensity, since it looks like the PCDLoader would be able to pull it out as a single value: https://github.com/mrdoob/three.js/blob/0fbae6f682f6e13dd9eb8acde02e4f50c0b73935/examples/jsm/loaders/PCDLoader.js#L429.

(In that case I think we'd need to use setXYZW below)

*/
const colorBuckets = (normProb: number): THREE.Vector3 => {
return colorMapGrey.map(([red, green, blue]) =>
new THREE.Vector3(red, green, blue).multiplyScalar(1 / 255))[probToColorMapBucket(normProb, colorMapGrey.length)]!;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does the .multiplyScalar(1 / 255) do?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this normalizes the pixels of colorMapGrey. So the vector3 will contain values of 0 to 1 instead of 0 to 255, which would match the expected values that colors wants

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GPUs usually like data normalized to 0-1 :)

@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 5, 2023
Co-authored-by: nicksanford <nicholascsanford@gmail.com>
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 5, 2023
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 5, 2023
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 6, 2023
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 6, 2023
@JohnN193 JohnN193 requested a review from nicksanford April 6, 2023 16:25
Copy link
Contributor

@jeremyrhyde jeremyrhyde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, requesting a re-review since I had some open questions and want to understand them before signing off.

* ticket to add testing: https://viam.atlassian.net/browse/RSDK-2606
*/
const probToColorMapBucket = (normProb: number, numBuckets: number): number => {
const prob = Math.max(Math.min(100, normProb * 255), 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[q] Isn't the normProb an integer between 1-100, why do we need to multiply it by 255? I would expect this to be:

const prob = Math.max(Math.min(100, normProb), 0);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the PCD loader actually sets the values on a scale from 0 to 1, which is why I referred to it as a normalized probability(normProb for short)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm @JohnN193 , for my understanding is it really a scale from 0 to 1, or is it 0 to 100/255?

Also, "normalized" seems to be its own concept in BufferAttribute so it'd be nice to avoid a name could be confused with that... could we simply call it 'probability'?

[note to self] carto_grpc_server sends back a value from 0-100, then PCDLoader divides by 255. We multiply by 255 here to bring it back to 0-100.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah for our implementation of a PCD from cartographer, normProb goes from 0-100/255. Because that isn’t a range I can guarantee for all slam algos I added the max/min bounds.

Fine with calling it probability. I picked the name just because I saw it was normalized but I don’t feel strongly about it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, calling it probability sounds good to me. Free tor resolve from my side.

@@ -8,6 +8,42 @@ import { MapControls } from 'three/examples/jsm/controls/OrbitControls';
import { PCDLoader } from 'three/examples/jsm/loaders/PCDLoader';
import type { commonApi } from '@viamrobotics/sdk';
/*
* // Leaving additional color map commented for if we want to change to a different scheme.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[minor] expand on this comment to state that this schema is used to map probability values (probability value ranges?) to colors specified by the schema

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tweaked the comment to try being more reflective of what the usage is

if (colors instanceof THREE.BufferAttribute || colors instanceof THREE.InterleavedBufferAttribute) {
for (let i = 0; i < colors.count; i += 1) {
const colorMapPoint = colorBuckets(colors.getZ(i));
colors.setXYZ(i, colorMapPoint.x, colorMapPoint.y, colorMapPoint.z);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@micheal-parks do you know why three.js uses setXYZ instead of something like setRGB for colors? Is it because the color type is a more generic THREE.BufferAttribute

* // Leaving additional color map commented for if we want to change to a different scheme.
* generated with: https://waldyrious.net/viridis-palette-generator/
* more info: https://cran.r-project.org/web/packages/viridis/vignettes/intro-to-viridis.html
* // const colorMapViridis = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[q] Why are we storing the colorMapViridis here if we are using the grayscale one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left the viridis colormap commented out so we could easily swap to it if after testing we found the greyscale color map did not perform the way we wanted

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha so the colorMapViridis is given to that grayscaler to produce our grayscale map?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the viridis color map is a separate mapping from the greyscale color map

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@EshaMaharishi just confirming we are alright having this alternative color schema as a comment in this file

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally I think it's better to remove unused code than leave it commented out, but I don't feel very strongly in this case if we think it's useful to have it available

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought, I think we should remove it. It's not great to accumulate commented out code in a codebase. It'll always be in the git history if we need it.

@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 6, 2023
@JohnN193 JohnN193 requested a review from jeremyrhyde April 6, 2023 21:33
Copy link
Contributor

@jeremyrhyde jeremyrhyde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just pinged @EshaMaharishi regarding the color schema comment but I am fine with whichever outcome we decide on

@@ -8,6 +8,44 @@ import { MapControls } from 'three/examples/jsm/controls/OrbitControls';
import { PCDLoader } from 'three/examples/jsm/loaders/PCDLoader';
import type { commonApi } from '@viamrobotics/sdk';
/*
* this color map is greyscale. The color map is being used map probability values of a PCD
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the comment update!

Copy link
Member

@EshaMaharishi EshaMaharishi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM mod comment about the name 'normProb'

// if the PCD has a color attribute defined, convert those colors using the colorMap
if (colors instanceof THREE.BufferAttribute || colors instanceof THREE.InterleavedBufferAttribute) {
for (let i = 0; i < colors.count; i += 1) {
const colorMapPoint = colorBuckets(colors.getZ(i));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for explaining!

It sounds like since carto_grpc_server is returning a PCD with format "x y z rgb" and putting a probability value 0-100 in the 'rgb' field. Since 0-100 is guaranteed to be less than 255, the probability will end up in the lowest byte, so we're able to pull it out by looking at the 'b' channel.

Agreed this is pretty roundabout. To consider in RSDK-2605: I wonder if we could use a PCD format "x y z intensity" and store the probability in intensity, since it looks like the PCDLoader would be able to pull it out as a single value: https://github.com/mrdoob/three.js/blob/0fbae6f682f6e13dd9eb8acde02e4f50c0b73935/examples/jsm/loaders/PCDLoader.js#L429.

(In that case I think we'd need to use setXYZW below)

* ticket to add testing: https://viam.atlassian.net/browse/RSDK-2606
*/
const probToColorMapBucket = (normProb: number, numBuckets: number): number => {
const prob = Math.max(Math.min(100, normProb * 255), 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm @JohnN193 , for my understanding is it really a scale from 0 to 1, or is it 0 to 100/255?

Also, "normalized" seems to be its own concept in BufferAttribute so it'd be nice to avoid a name could be confused with that... could we simply call it 'probability'?

[note to self] carto_grpc_server sends back a value from 0-100, then PCDLoader divides by 255. We multiply by 255 here to bring it back to 0-100.

* // Leaving additional color map commented for if we want to change to a different scheme.
* generated with: https://waldyrious.net/viridis-palette-generator/
* more info: https://cran.r-project.org/web/packages/viridis/vignettes/intro-to-viridis.html
* // const colorMapViridis = [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally I think it's better to remove unused code than leave it commented out, but I don't feel very strongly in this case if we think it's useful to have it available

@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 10, 2023
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 10, 2023
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Apr 10, 2023
@github-actions
Copy link
Contributor

Code Coverage

Package Line Rate Delta Health
go.viam.com/rdk/components/arm 64% 0.00%
go.viam.com/rdk/components/arm/fake 30% 0.00%
go.viam.com/rdk/components/arm/universalrobots 40% 0.00%
go.viam.com/rdk/components/arm/wrapper 19% 0.00%
go.viam.com/rdk/components/arm/xarm 6% 0.00%
go.viam.com/rdk/components/arm/yahboom 6% 0.00%
go.viam.com/rdk/components/audioinput 53% -0.34%
go.viam.com/rdk/components/base 61% 0.00%
go.viam.com/rdk/components/base/agilex 62% 0.00%
go.viam.com/rdk/components/base/boat 41% 0.00%
go.viam.com/rdk/components/base/wheeled 76% 0.00%
go.viam.com/rdk/components/board 65% -0.15%
go.viam.com/rdk/components/board/arduino 10% 0.00%
go.viam.com/rdk/components/board/fake 38% 0.00%
go.viam.com/rdk/components/board/genericlinux 22% 0.00%
go.viam.com/rdk/components/board/numato 19% 0.00%
go.viam.com/rdk/components/board/pi 50% 0.00%
go.viam.com/rdk/components/camera 64% +0.25%
go.viam.com/rdk/components/camera/align 64% 0.00%
go.viam.com/rdk/components/camera/fake 71% 0.00%
go.viam.com/rdk/components/camera/ffmpeg 76% -1.43%
go.viam.com/rdk/components/camera/rtsp 44% 0.00%
go.viam.com/rdk/components/camera/transformpipeline 78% 0.00%
go.viam.com/rdk/components/camera/videosource 34% 0.00%
go.viam.com/rdk/components/encoder 15% 0.00%
go.viam.com/rdk/components/encoder/fake 76% 0.00%
go.viam.com/rdk/components/gantry 58% 0.00%
go.viam.com/rdk/components/gantry/multiaxis 85% 0.00%
go.viam.com/rdk/components/gantry/oneaxis 86% 0.00%
go.viam.com/rdk/components/generic 82% 0.00%
go.viam.com/rdk/components/gripper 67% 0.00%
go.viam.com/rdk/components/input 86% 0.00%
go.viam.com/rdk/components/input/fake 86% 0.00%
go.viam.com/rdk/components/input/gpio 84% 0.00%
go.viam.com/rdk/components/motor 76% 0.00%
go.viam.com/rdk/components/motor/dimensionengineering 63% 0.00%
go.viam.com/rdk/components/motor/dmc4000 69% 0.00%
go.viam.com/rdk/components/motor/fake 56% 0.00%
go.viam.com/rdk/components/motor/gpio 66% +0.41%
go.viam.com/rdk/components/motor/gpiostepper 51% -0.61%
go.viam.com/rdk/components/motor/tmcstepper 62% 0.00%
go.viam.com/rdk/components/motor/ulnstepper 52% 0.00%
go.viam.com/rdk/components/movementsensor 74% 0.00%
go.viam.com/rdk/components/movementsensor/adxl345 66% 0.00%
go.viam.com/rdk/components/movementsensor/cameramono 45% 0.00%
go.viam.com/rdk/components/movementsensor/gpsnmea 36% 0.00%
go.viam.com/rdk/components/movementsensor/gpsrtk 29% 0.00%
go.viam.com/rdk/components/movementsensor/mpu6050 83% 0.00%
go.viam.com/rdk/components/posetracker 84% 0.00%
go.viam.com/rdk/components/sensor 66% 0.00%
go.viam.com/rdk/components/sensor/ultrasonic 31% 0.00%
go.viam.com/rdk/components/servo 66% 0.00%
go.viam.com/rdk/components/servo/gpio 71% 0.00%
go.viam.com/rdk/config 78% 0.00%
go.viam.com/rdk/control 57% 0.00%
go.viam.com/rdk/data 77% 0.00%
go.viam.com/rdk/examples/customresources/demos/remoteserver 0% 0.00%
go.viam.com/rdk/grpc 25% 0.00%
go.viam.com/rdk/ml 67% 0.00%
go.viam.com/rdk/ml/inference 70% 0.00%
go.viam.com/rdk/module 67% 0.00%
go.viam.com/rdk/module/modmanager 80% 0.00%
go.viam.com/rdk/motionplan 71% +0.05%
go.viam.com/rdk/operation 82% 0.00%
go.viam.com/rdk/pointcloud 69% 0.00%
go.viam.com/rdk/protoutils 49% 0.00%
go.viam.com/rdk/referenceframe 72% 0.00%
go.viam.com/rdk/registry 83% 0.00%
go.viam.com/rdk/resource 84% 0.00%
go.viam.com/rdk/rimage 78% 0.00%
go.viam.com/rdk/rimage/depthadapter 94% 0.00%
go.viam.com/rdk/rimage/transform 75% 0.00%
go.viam.com/rdk/rimage/transform/cmd/extrinsic_calibration 67% 0.00%
go.viam.com/rdk/robot 87% +0.91%
go.viam.com/rdk/robot/client 82% 0.00%
go.viam.com/rdk/robot/framesystem 65% 0.00%
go.viam.com/rdk/robot/impl 81% 0.00%
go.viam.com/rdk/robot/packages 80% 0.00%
go.viam.com/rdk/robot/server 53% 0.00%
go.viam.com/rdk/robot/web 64% 0.00%
go.viam.com/rdk/robot/web/stream 87% 0.00%
go.viam.com/rdk/services/baseremotecontrol 71% 0.00%
go.viam.com/rdk/services/baseremotecontrol/builtin 78% 0.00%
go.viam.com/rdk/services/datamanager 75% 0.00%
go.viam.com/rdk/services/datamanager/builtin 85% 0.00%
go.viam.com/rdk/services/datamanager/datacapture 73% 0.00%
go.viam.com/rdk/services/datamanager/datasync 0% 0.00%
go.viam.com/rdk/services/mlmodel 83% 0.00%
go.viam.com/rdk/services/motion 53% 0.00%
go.viam.com/rdk/services/motion/builtin 86% 0.00%
go.viam.com/rdk/services/navigation 54% 0.00%
go.viam.com/rdk/services/sensors 74% 0.00%
go.viam.com/rdk/services/sensors/builtin 97% 0.00%
go.viam.com/rdk/services/shell 25% 0.00%
go.viam.com/rdk/services/slam 84% 0.00%
go.viam.com/rdk/services/slam/builtin 74% 0.00%
go.viam.com/rdk/services/slam/fake 90% 0.00%
go.viam.com/rdk/services/slam/slam_copy/config 97% 0.00%
go.viam.com/rdk/services/slam/slam_copy/dataprocess 71% 0.00%
go.viam.com/rdk/services/slam/slam_copy/utils 100% 0.00%
go.viam.com/rdk/services/vision 79% 0.00%
go.viam.com/rdk/services/vision/builtin 74% 0.00%
go.viam.com/rdk/session 97% 0.00%
go.viam.com/rdk/spatialmath 84% 0.00%
go.viam.com/rdk/subtype 92% 0.00%
go.viam.com/rdk/utils 72% -0.18%
go.viam.com/rdk/vision 26% 0.00%
go.viam.com/rdk/vision/chess 80% 0.00%
go.viam.com/rdk/vision/delaunay 87% 0.00%
go.viam.com/rdk/vision/keypoints 92% 0.00%
go.viam.com/rdk/vision/objectdetection 82% 0.00%
go.viam.com/rdk/vision/odometry 60% 0.00%
go.viam.com/rdk/vision/odometry/cmd 0% 0.00%
go.viam.com/rdk/vision/segmentation 49% 0.00%
go.viam.com/rdk/web/server 26% 0.00%
Summary 65% (22917 / 35025) 0.00%

@JohnN193 JohnN193 merged commit 97370ce into viamrobotics:main Apr 10, 2023
@JohnN193 JohnN193 deleted the RSDK-1705-colormap branch March 22, 2024 17:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
appimage Build AppImage of PR safe to test This pull request is marked safe to test from a trusted zone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants