Processed Image > Robot Movement Help Needed

Technical NI LabVIEW
#21

What would you recommend doing? I redid the vision processing to make sure distance works now (which it does, thanks for the help on that).

But now I’m working on integrating it into something I can work with in teleop. I would like to have it read the distance data value and while both the button being pressed is true, and the distance value being greater than a certain number is true, drive forward until that is no longer true.

Here is what I have for teleop.vi at this point in regards to vision (now that I’ve started over):

#22

I attached an image with a few edits.

You were heading in the right direction, but making a few wrong turns.

Your code was reading “Left and Right Motors” from both RobotDrive and also from the Motors list. While this is supported, I suspect you were really meaning to update robot drive again. Please correct me if I’m wrong.

The next thing to think about is what the result is when a motor is given multiple commands during a teleOp execution or in parallel portions of the app. The better approach is to combine the logic and update the motors or other actuators just once. That is what I attempted to show I’m my modified image. You bring the joystick and the distance info into a single switch statement. You can update the motors either in a common location using outputs.

A slight variation that you may see or decide to use is to bring the values together and use a ternary ?: operator to select one of them to go to the motors.

Greg McKaskle

Untitled-1.png
Untitled-1.png835×437 9.45 KB



Untitled-1.png
Untitled-1.png835×437 9.45 KB

#23

I fixed the code and ran it on the robot, but I kept getting “Error Code 74: Unflatten from String in periodic task.vi > robotmain.vi “Memory corrupt”” when I move the joystick. Am I forgetting to do something with the unflatten?

EDIT: Woops, I wasn’t sending the right data from the dashboard to the robot (I was tinkering around with different ways to send it and forgot to undo it)

EDIT 2: This is the error I’m getting when running it now:

ERROR <Code> -44061 occurred at “Left and Right Motors” in the VI path: Robot Main.vi
<time>00:00:58 01/01/1970
FRC: The loop that contains RobotDrive is not running fast enough. This error can occur if the loop contains too much code, or if one or more other loops are starving the RobotDrive loop.

#24

That message is telling you that your RobotDrive wasn’t updated for over 100ms. So the safety mechanism set it to zero for you. This is a good thing if you happen to be debugging your code or you slow it down accidentally.

Do you know which loop it is referring to? It may just be in your teleop. Do you see any reason why teleop would take a long time to finish? A common issue is to place a delay to sequence an action directly into teleop when a button is pressed or a target is seen. This causes that iteration of teleop to take a long time and the message is printed.

If you see many of these messages, it may be worth instrumenting teleop and other loops to see how often they are running. To do this, the project window has a folder called support code. The Elapsed Times VI can be placed into the teleop or other loops. Then run the code on the robot in debug mode and open the Elapsed Times panel. It will show you the delta between each call. Between this and the CPU usage on charts, you can identify if loops are running faster than you need, slower than you want, etc.

Greg McKaskle

#25

It works!

#26

Congrats. Care to share why the issue was or what settings you changed to get it working?

Greg McKaskle

#27

Yeah I plan on putting together a start to finish tutorial asap. That was my main issue was with doing vision. There are (great) whitepapers out there on how do complete certain steps, but I haven’t seen a complete guide along with options for things to do with your robot once you can see.\

The issue was the actual drive code was being starved of information due to a case structure that filtered the flow of data to it. The workaround was allowing the drive code to constantly receive information even if it’s 0. The problem was not overflow of code or something running too slow (e.g. too much data analysis in teleop.vi). Another thing that helped was to only send through the distance values as a double instead of the entire distance + hot? + left? + xy coords as a flattened and then unflattened string, although that is still possible we just don’t see a need for all of that right now.

#28