FTC 11260 Up-A-Creek Robotics Progress Updates

[MatthewOates36]

We picked up our Systemcore at worlds and flashed the latest OS. We installed Wpilib 2027.0.0-alpha-6 on an M1 Macbook Pro for development. On the same laptop we also installed the FirstDriverStation to control the robot.

For a first test we placed the Systemcore on our Decode robot Epoch. We used OpModeRobot to make a simple Teleop to drive the robot. Video here. We saw some instances of the controls stuttering but have not had an opportunity to investigate.

The setup and development flow was straightforward (LOVE the deploy times). One question that came up in our initial testing was what is the easiest way to view the logs from our robot code. The only way we found so far was to use the Systemcore web UI but this seems non-ideal.

[blaze-developer]

By logs from your robot code, do you mean any live data, or data that's recorded to a file?

For most types of log information AdvantageScope can be used to download log files from the robot, view live data, and analyze them off of the robot network. There is a 2027 version included in the WPILib alpha, and on their github.

Let me know if you meant something else though.

[ThadHouse]

Right now, thats kind of the best way to grab console logs. We're eventually going to have a way to forward those logs to the DS like the existing roboRIO setup, but that hasn't been implemented on the robot side.

However, would definitely recommend using SmartDashboard APIs currently (These will be replaced soon, but they still work for now), and using a dashboard to do data logging, like Blaze said above.

[MatthewOates36]

This week we received our A301 motors and set them up. First we installed the REV hardware manager on the Systemcore which went smoothly. We then were able to download the A301 firmware update directly from the REV hardware manager by plugging the Systemcore into Ethernet. The firmware update again went smoothly. Adding REVLib to our codebase from the URL was straight forward and we wrote a program to run a motor at a constant velocity.

This is where we ran into our first issue. When we ran this OpMode the motor would only run intermittently. We saw nothing to explain this on the driver station, but when we checked the Systemcore logs we saw lines mentioning the watchdog. This behavior also seemed similar to what we saw last week running the hybrid configuration when the robot would briefly stop running. We tried a few things to resolve this before finding that when we plugged the driver station laptop into the Systemcore via Ethernet the interruptions went away. When plugged into Ethernet the driver station reports pings of ~1ms, when we were seeing dropouts on WiFi the driver station reported pings in the 10-40ms range.

The next test we did was to drive the A301 in velocity mode with a square wave to look at the response time. Below is a plot showing a rising edge with the requested velocity in blue and the reported velocity in yellow. In this test we saw response times in the range of 120-160ms. This seems surprisingly high especially given the same test in the hybrid configuration with a DC motor yielded times around 50ms. Running the same test on the A301 in voltage mode showed marginally better response times but still generally over 100ms.

[gearsincorg]

Hi Mathew.

We (2818) have been running our Systemcore exclusively via WiFi, and have not seen any motor intermittancy issues.
I'm running windows. Perhaps there is some DS issue with using a Macbook.
Do you have access to a Windows PC to compare, to see if it's the DS or the SC.

You show some interesting latency information.
I was also trying to determine the end-end response times of the system, but I was using digital in/out.
I ran into the problems that:
a) The opmode runs on a 50 mS cycle, so it's hard to measure anything faster than that. (creating a faster period had limited success)
b) The I/O was asynchronous, so it's hard to know when commands actually actioned (vs called), and some are ignored if issued too frequently.

Because of the 20 Hz opmode period, any motor response between 101 and 149 ms will look like 150ms, so it's hard to get an accurate measurement. How would this response compare with the current Control Hub?

Looking at the motor response on my own system (once it starts moving), it also looked to be tuned with more focus on stability rather than responsiveness. I wonder if this is just a safety factor while they learn more about the motors.

[MatthewOates36]

We are planning to try a Windows laptop as a DS tonight so we'll report back.

After reading your work probing the DIO we ran this test with a 5 ms period so we'd get a more precise measure of the time from first call to observed response. Looking at how frequently the measured velocity changes on the graph it appears the slowest asynchronous period between the A301 and our OpMode is at a 50 ms.

Running this same test in the hybrid configuration we observed response times around 50 ms on a motor and saw the measured velocity update every 8-12 ms. This was only running a single motor so I would imagine a fully loaded Expansion Hub with an OpMode issuing lots of actuator commands would slow the velocity read frequency given the known limitations in the Expansion Hub's serial processing of commands. I believe these numbers are similar to what we've seen in the past from a Control Hub but I don't have hard data from that at the moment.

[ThadHouse]

My guess is Rev has configured the A301 to send status updates at 20 Hz, which is why thats how often updates occur. I would expect a lot more on board PID usage, which avoids any CAN status packet rates and can run onboard much faster.

ExHub runs at 82 Hz at all times, so you'll get those update rates no matter if you're running 1 motor or all 4. The way it works is completely different from how the existing FTC SDK talks to the Expansion Hub Boards. That is actually why RS485 isn't supported, and instead each ExHub must be in its own USB port. That way we can talk to both in parallel at 82 Hz.

[jfabellera]

Looks like the periods for status messages are not correct... that should be fixed in an upcoming firmware release, and the ability to configure the periods will come in a later update