2019 Howdy Bots 6377 Code Release

The Howdy Bots team is proud to release its code for Outlaw, our robot for the FRC 2019 game Destination: Deep Space, and a proud member of the #FlippersClub

Github repository: https://github.com/frc6377/2019-Code-Publish

You can read more about the approach we took in the PDF document included with the repository: How it’s made.

Highlights:

  • Programming Language: NI LabVIEW
  • Architecture: Object-oriented LabVIEW classes for each subsystem, which are encapsulated in subsystem libraries.
  • Dynamic loading of code using a configuration file that provides both constant values for motor controllers and I/O references, as well as the class type to load for each subsystem.
  • Limelight integration: Use of limelight to control the robot’s alignment in the field.

Fun Facts:

  • Use in multiple robots: This code was written to control our 2019 robot: Outlaw. However, because of the system-based approach we took, it can also be used to control both our 2018 robot: PacBot, as well as our off-season testing robot.
  • Leveraging VIMs: Use of malleable VIs to provide adaptable code modules that automatically compile to work one of multiple supported data types.
  • Extending capabilities with CTRE: Used the Talon SRX motor controllers to offload the closed loop control from the NI roboRIO to each controller, thus allowing us to control mechanisms such as the flipping arm by just sending position commands.

Let us know which questions you have while exploring our solution.

1 Like

Did your team run into any strange issues or performance problems using LVOOP? I’m sure its better in LabVIEW 2018/2019, I recall there being issues a few years ago with it, and there is often concern when talking about using it with other experienced LabVIEW developers.

For example our team had a single LVOOP class at one point in 2016, and at one point seemingly randomly our code no longer built or ran at all, and the only indication that something was wrong was some generic error code (i.e. no broken run arrow). This was between matches at champs, and the only fix we found was to completely tear out the LVOOP code.

I was worried about that, too, as the team went into using this solution. However, because they allocate the objects during initialization and ensure they do not make memory copies of them (by using the In Place Element structure in the Teleop.vi), the code runs properly and within the 20 ms loop time.

There was an interesting problem that would slow down the code when having complex arrays inside a class’ private data, and that’s why the class’ stores a string to fetch resources from the Refnums FGV, instead of storing them in the object itself.

I don’t recall build/deployment problems that could not be solved by clearing the object cache in the machine. The team also disabled the Camera stream to the Dashboard to provide more RAM to the code, and because they use a Limelight, which offloads the burden of opening video sessions from the roboRIO.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.