Processed Image > Robot Movement Help Needed

[BenGrapevine]

(dashboardmain.vi)


(periodictasks.vi)


Looking at the flatten to string, it appears the data coming in is a 1D array. I have no clue what you mean by dragging and dropping stuff from there to the 'type' in the unflatten from string.

[Greg McKaskle]

Actually, I'd suggest right-clicking on the Distances indicator terminal. Choose Create >> Constant. This creates a constant of the same datatype. Use the mouse to drag the constant from your dashboard VI's block diagram to the periodic VI's block diagram. If this is awkward, you can copy and paste. You can then delete the constant from the dashboard diagram.

Then wire the constant to the Type input. Next you can unbundle the data front he unflatten or otherwise share the data via globals.

Greg McKaskle

[BenGrapevine]

Okay so I followed your instruction here and added the distances to work on a joystick button like so:



On button3 and once checked if the distance is >= 6 feet, drive forward. This seems like it would work fine but I have no idea why it's not calculating distance information:



As you can see on the dashboard, in both places the distance is indicated as 0. What am I doing wrong?

[BenGrapevine]

I've modified the dashboard so that the smaller "distances" panel next to the HSV control now displays hot/not hot and lights up when it is "left", what still doesnt show up is distance and target to center. Do I need to do something with the computing distances vi to allow it to calculate?

[Greg McKaskle]

I'd suggest opening additional subVI panels to see what is causing the zero distance. The Calc distance is based on the camera type and is pretty simple trig. Does it make more sense now?

Another thing looks odd in the joystick button code you attached. It unbundles a double and compares it to 6. The double numeric seems to be coming from a constant. I suspect that should be the distance value that is being communicated and unflattened.

Greg McKaskle

[BenGrapevine]

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):

[Greg McKaskle]

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

[BenGrapevine]

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.

[Greg McKaskle]

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

[BenGrapevine]

It works!

[Greg McKaskle]

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

Greg McKaskle

[BenGrapevine]

Originally Posted by Greg McKaskle

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

Greg McKaskle

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.