Add support for DX200

[gavanderhoorn]

tasks:

• add support for DX200 controllers to build system for M+ libmicroros (Add support for DX200 #18 (comment))
• add DX200 to VS project configurations and related support files (.mps)
  • Humble only (for now)
• add DX200 version of MotoROS_PlatformLib binary
• add DX200 version of ParameterExtraction binary
• add/replace mpCtrlGrpNo2GrpId(..)
• need to read config file from USB instead of SRAM
• investigate potential issues with mpGetEncoderTemp (might not be available on DX200 / certain YCP versions)
  • available since DN2.44 -> updated requirements in doc
• need to read robot calibration data
• need to add gettimeofday(..) support (introduced by Adding a timestamp to debug messages #61)
  • no longer needed: Switch to clock_gettime(..) #99

Known issues (from previous testing):

• the command to create the node is returning an error code RCL_RET_NODE_INVALID_NAME. (I haven't done any debug on it yet.)
  • has not been observed again yet
• SUBCODE_FAIL_NODE_INIT when calling rclc_node_init_with_options(..) (returns 1) (Support for DX200 controllers #49 (comment))
  • probably the result of an outdated Agent: Support for DX200 controllers #49 (comment)

[gavanderhoorn]

@smith-doug @robinsonmm FYI

[gavanderhoorn]

@ted-miller: M+ libmicroros build setup seems functional for DX200.

Test build output: 1685697608_libmicroros_humble-20221102_dx200.zip.

---

Edit: with this test build and a temporary work-around for need to read robot calibration data, a DX200 build seems to succeed.

[gavanderhoorn]

@smith-doug @robinsonmm: would the robot you could potentially use to test this happen to be mounted on a rail/track? If it isn't, we might be able to provide you with a test-build sooner.

[acbuynak]

If helpful as a test case, I can offer a 12-axis (2 x 6R arms) system controlled by two DX200's in a master-slave configuration.

[gavanderhoorn]

@acbuynak: if you would be ok with incorrect TFs for now, we'd gladly take you up on that offer.

[acbuynak]

Happy to help. I am okay with incorrect TFs.

[ted-miller]

Missing mpGetEncoderTemp.

[ted-miller]

hmm... I looks like Ros_CtrlGroup_GetEncoderTemperature is not actually used. I suspect this was copied from MotoROS1 in anticipation of future functionality. We should just remove it for now.

[gavanderhoorn]

I'm almost certain DN3.19.00a does have mpGetEncoderTemp(..), and that's the version I verified symbols against. It's also listed in mpLegApi00.h of the M+ SDK v1.4.4?

hmm... I looks like Ros_CtrlGroup_GetEncoderTemperature is not actually used. I suspect this was copied from MotoROS1 in anticipation of future functionality. We should just remove it for now.

We (I) added that about a year ago. Preparation for publishing controller statistics.

[robinsonmm]

@gavanderhoorn our DX200 is NOT on a track.

[gavanderhoorn]

@robinsonmm: then it would be great if you could perhaps also test the alpha1 binary linked in #49 (comment).

It's expected to not work, but the test would help figure out at which point it breaks.

[ted-miller]

wrt #49 (comment)

I did some more "debugging" and got some weird results.

My initial assumption was that there is an problem with the semaphore routines in microxrcedds_client. My thought was that the UXR_LOCK_SESSION was failing in uxr_run_session_until_all_status. So I added some debug broadcasts if those fail. Those broadcasts never happened, so I have to assume that the sems are ok. But at this point, rclc_support_init_with_options is still failing at startup.

So just to get a look at what is failing, I put a broadcast here, where the status-code is checked. When running this build, rclc_support_init_with_options is no longer failing. MotoROS2 initialization completes successfully. (I didn't change anything other than the Ros_Debug_Broadcast.)

However, when I attempt to use any of the CLI utilities, they just freeze up and hang. But I'm not sure whether that's due to failed communication with the robot or because I'm using a Windows Agent and CLI. Frankly, I've seen some oddities with my Windows setup and don't fully trust it.

When I get my Ubuntu machine back, I'll try again to see if it works any better.

But I'm struggling to understand how adding the debug broadcast changed the behavior. I guess it might affect timing a little... but it shouldn't be significant.

[ted-miller]

Oh, also rcutils_get_error_string doesn't have any information. It just reports error not set.

[gavanderhoorn]

So just to get a look at what is failing, I put a broadcast here, where the status-code is checked. When running this build, rclc_support_init_with_options is no longer failing. MotoROS2 initialization completes successfully. (I didn't change anything other than the Ros_Debug_Broadcast.)

hm. Maybe some optimisation the compiler can now no longer apply?

Which M+ libmicroros version are you using? The one I shared in #18 (comment), or something else?

---

Edit: session.c.obj in the build shared in #18 (comment) and the one in the current YRC libmicroros are identical (at least when looking at the uxr_run_session_until_all_status(..) function).

---

Edit 2: that function calls uxr_millis(..) in multiple places. I'm still not 100% sure the underlying platform code is correct / has the expected resolution on YRC / DX2.

[ted-miller]

hm. Maybe some optimisation the compiler can now no longer apply?

Possible. There was once a long time ago that compiler optimizations broke my application. It took me a LONG time to debug that and that's why I always use -O0 for everything.

Which M+ libmicroros version are you using?

I had to build from source to insert my debug broadcasts.

When I get my Ubuntu machine back, I'll try again to see if it works any better.

Yep... my Ubuntu machine is able to list/echo topics just fine. So now I really don't trust my Windows build and I have no idea why the DX200 build is actually working.

[gavanderhoorn]

hm. Maybe some optimisation the compiler can now no longer apply?

Possible. There was once a long time ago that compiler optimizations broke my application. It took me a LONG time to debug that and that's why I always use -O0 for everything.

hmhm.

Which M+ libmicroros version are you using?

I had to build from source to insert my debug broadcasts.

Ok, so that should all be -O0 then.

When I get my Ubuntu machine back, I'll try again to see if it works any better.

Yep... my Ubuntu machine is able to list/echo topics just fine. So now I really don't trust my Windows build and I have no idea why the DX200 build is actually working.

that's 🎉 and 😟 at the same time.

[gavanderhoorn]

Stupid and perhaps unrelated, but sendto(..) is a cancellation point in glibc and on various RTOS. I've not verified whether that's true on VxWorks, but Ros_Debug_BroadcastMsg(..) calls mpSendTo(..). Perhaps calling that allows the scheduler to swap in some other task, something gets updated and that's why it works with the call, but stops working without it?

Would be interesting to see what happens if you replace the Ros_Debug_BroadcastMsg(..) with an mpTaskDelay(1).

[smith-doug]

Is it possible to get a Foxy version for the DX200? I don't have the DX200 SDK anymore. Our robot is currently set up for a project using Foxy.

[ted-miller]

When I get my Ubuntu machine back, I'll try again to see if it works any better.

Yep... my Ubuntu machine is able to list/echo topics just fine. So now I really don't trust my Windows build and I have no idea why the DX200 build is actually working.

I just did a foxy build (unmodified) and it worked immediately with my Ubuntu agent. I'm wondering if the humble errors were entirely due to my windows agent. I'll need to test a vanilla humble build again tomorrow. (and/or redo my windows setup)

[gavanderhoorn]

#61 introduced use of gettimeofday(..) which does not appear to be (directly) supported on DX200.

I've updated the OP.