CRIO-FRCIII

[NotInControl]

Originally Posted by yash101

Thanks for your help.... I wonder what FIRST has in mind for these current sensors. They maybe useful for reporting faults automatically to the FMS so they can be prepared to look for specific problems!

I'd like to preface that my response is speculative... but I doubt FIRST has any specific plans for the current sensors. They are provided for Teams use how ever they seem fit, it at all. Most teams will do just fine without current sensing (like a majority do now).

Remember, as of right now, the only way to have access to the current readings is to wireup the CAN bus between the Rio and the PDP.

In order for FIRST to pull off what you are proposing, they would have to force every team to wire that bus, and have default code on the RoboRio that reads current off those channels.

I am not an expert on FMS/Driverstation communications, but as far as I know, the Driverstation only talks to a small part of code on the cRIO to control Robot State, and UDP a couple of status parameters back.

While it is possible for FIRST to pull off something like what you suggest, I think it is very unlikely that they ever will. Usually a stalled Motor is not the cause of a Robot loosing comms unless it is pulling the batter voltage down below the brownout point of the CRIO or D-link. The #1 priority of FIRST FTA'a is to make sure your Robot maintains FMS connectivity, not diagnose your build faults: that what other gracious teams help with .

Frankly, I would rather FIRST limit the amount of reach they have within User code than expand it.

Hope this helps,
Kevin

[yash101]

Originally Posted by NotInControl

I'd like to preface that my response is speculative... but I doubt FIRST has any specific plans for the current sensors. They are provided for Teams use how ever they seem fit, it at all. Most teams will do just fine without current sensing (like a majority do now).

Remember, as of right now, the only way to have access to the current readings is to wireup the CAN bus between the Rio and the PDP.

In order for FIRST to pull off what you are proposing, they would have to force every team to wire that bus, and have default code on the RoboRio that reads current off those channels.

I am not an expert on FMS/Driverstation communications, but as far as I know, the Driverstation only talks to a small part of code on the cRIO to control Robot State, and UDP a couple of status parameters back.

While it is possible for FIRST to pull off something like what you suggest, I think it is very unlikely that they ever will. Usually a stalled Motor is not the cause of a Robot loosing comms unless it is pulling the batter voltage down below the brownout point of the CRIO or D-link. The #1 priority of FIRST FTA'a is to make sure your Robot maintains FMS connectivity, not diagnose your build faults: that what other gracious teams help with .

Frankly, I would rather FIRST limit the amount of reach they have within User code than expand it.

Hope this helps,
Kevin

This could be a feature added into the roboRIO control system before it is deployed, so I think it might be a bit too early to say that it will be very hard for them to do. My point is so they can detect fatal faults to keep the robot safe. What if a motor/controller combo shorts out and pulls 120 amps? The FMS might be able to shut it down instead of allowing the breaker to open, thus crashing the entire bot! I think 75% of a robot is better than 0%. At least the robot will be able to drive around and possibly defend and use it's other mechanisms to score!

[NotInControl]

Originally Posted by yash101

This could be a feature added into the roboRIO control system before it is deployed, so I think it might be a bit too early to say that it will be very hard for them to do.

I prefaced my previous post with "my response is speculative" so as to not have people assume it to be fact. I am not a representative of FRC, FIRST, or NI, and the statement I made in that post were purly based on my experiences thus far with FRC (based on 10+ years).... However, without side-tracking this post too much I will entertain your comment and offer this:

First, I never said it was hard for them to do. But I speculate it is additional work they will not likely do, as it requires more changes, with not a lot of benefit. As a FRC member about to experience a control system transistion one would advocate that FIRST should focus on a seamless transition, not adding more complexity to the mix. Please re-read my previous post if it was unclear. I stated "While it is possible for FIRST to pull off something like what you suggest, I think it is very unlikely that they ever will." I never said it was hard. Try not to misquote.

Originally Posted by yash101

My point is so they can detect fatal faults to keep the robot safe. What if a motor/controller combo shorts out and pulls 120 amps? The FMS might be able to shut it down instead of allowing the breaker to open, thus crashing the entire bot! !

Fault detection is to keep people safe first, robot safe second. Since you are presenting this system as a good idea, you must be able to articulate how it works. If I understand correctly, you wish FMS can "shut it down" in lieu of a breaker being tripped. You would replace a mechanical device (a breaker) with a control system. As a control engineer or System designer, you need to think about reaction time, bounding limits, false detections, etc. Do you believe your control system will react faster then a mechanical breaker in the case you describe? What if the short was on the roborio - such that comms were lost. What is the reason you wish to agument the breakers? I believe the mechanical system wins!

What about instances when you power the robot on and don't have a driverstation connected? What does your system do in that case? The breakers still function but FMS doesn't

Originally Posted by yash101

I think 75% of a robot is better than 0%. At least the robot will be able to drive around and possibly defend and use it's other mechanisms to score!

However for conversation purposes, Lets say we could augment the system and have FMS current monitoring in the loop. How do you plan to shut down a channel on the PDP, while allowing other channels to operate? This functionaility does not exist. If the breaker is inline, and not tripped, power will still be provided, nothing in software can prevent this currently. The channels are not individually controlled. I believe your statement of "the FMS can shut it down instead of allowing a breaker to open" is backwards. If a breaker opens, the rest of the robot still gets power. If FMS shuts the robot down, the whole robot goes down.

I am not sure what you mean here. Or how the system you describe actually works. Please think about the questions I ask, and try to rearticulate your system and how it behaves in those scenarios provided.

These questions are not to shot your ideas down so please do not take them that way. I ask them so you can be prepared to answer them as you articulate how the system you describe works.


Hope this helps,
Kevin

[yash101]

A typical breaker doesn't open immediately. It takes easily 1-3 seconds. This would have to be more of a watchdog feature, but if the load on a specific port on the PDB is too high for too long, not just a spike, it will open a relay and the fault shall no longer persist. With an FPGA onboard, it should be easy to make this extremely reliable and fast! The delay before trip would also be adjustable, instead of random (within a range)

[Jon Stratis]

One thing to note: I believe they are planning on using the PDB CAN interface for battery voltage monitoring, similar to the way they do today with the jumper on the analog breakout. That should make it very easy to help teams get some monitoring in place if they need it, since it'll already be wired up!

[NotInControl]

Originally Posted by yash101

A typical breaker doesn't open immediately. It takes easily 1-3 seconds.

Not true for the scenario you presented (short drawing 120A). The breakers react to thermal change. A 40A breaker (max allowed in FRC) seeing a 120A draw will react within 0.5 - 1.1s (300% load over rating).

Check the spec...
http://www.snapaction.net/pdf/MX5%20Spec%20Sheet.pdf

Originally Posted by yash101

This would have to be more of a watchdog feature, but if the load on a specific port on the PDB is too high for too long, not just a spike, it will open a relay and the fault shall no longer persist.

This thread is getting side tracked by this discussion. I admit I do not understand how the system you propose works. And I don't think given the current design of the hardware, it is even possible. It sounds like you want to add built-in relays to the PDP board as well as modify FMS and the driverstation to read current from the PDP. Without understanding how your system works, all I can say is make your request to FIRST, NI, or CTRE to see if they like it. If your system requires modification to the hardware (I assume this because I don't know what relay you speak of, or where it exists), then state that.

Originally Posted by yash101

With an FPGA onboard, it should be easy to make this extremely reliable and fast! The delay before trip would also be adjustable, instead of random (within a range)

The FPGA only exist on the ROBORio not the power distro panel. It appears that you are proposing a system which relies on the CAN bus to be active, and the ROBORio FPGA to be functioning (powered/not crashed etc), as well as the Driverstation in the loop, and possibly FMS. These are a lot of variables in a system which is to determine what happens to a robot during a fault. Food for thought? How does your system work in the event one of those systems is not in the loop? How does your system work with the current hardware? If you wish to continue this discussion, I suggest you open a separate thread.

Originally Posted by Jon Stratis

One thing to note: I believe they are planning on using the PDB CAN interface for battery voltage monitoring, similar to the way they do today with the jumper on the analog breakout. That should make it very easy to help teams get some monitoring in place if they need it, since it'll already be wired up!

I remember Joe for NI stating that the battery voltage on the Driverstation will be polled directly from the inputs of the RoboRIO. This is possible because there is no longer a boost supply on the power supply to the RoboRio from the PDP board. So I do not believe the CAN bus is a requirement for voltage monitoring. Obviously this can change.

Regards,
Kevin

[Greg McKaskle]

As mentioned, the cRIO is a 24V device on a 12V robot. It isn't connected directly to the battery. The roboRIO will connect straight to the 12V circuit of the PD. It will monitor voltages directly for battery and for its internal supplies. It will indeed have monitoring and will shutdown systems in brown-out situations. The cRIO does that today, but it can only measure if the analog module is wired.

Greg McKaskle

[rfolea]

Since the roboRio is a 12V device, I hope they will keep the 24V on the PD so we can use it for things like 24V solenoids, etc ....

[Jefferson]

Originally Posted by rfolea

Since the roboRio is a 12V device, I hope they will keep the 24V on the PD so we can use it for things like 24V solenoids, etc ....

The Pnuematics Control Module has a jumper to select either 12 or 24 V outputs to the solenoids.

[Bryan Herbst]

Originally Posted by BBray_T1296

Will the new system be finally able to run at higher connection speeds so we are not stuck in early 2000s with 360p 50% compression 5fps video feeds?

I realize that it is more of a FMS problem than the robot side stuff, but will the FMS get a much-needed upgrade as well?

Why do you need a higher quality video stream? You should be able to get much better quality than what you described and still be well within the 7 Mbps limit. I have yet to see a team that even noticed a difference in their video quality when they turned it down to get around 3 Mbps.

Most teams' video streams are about 2 square inches on their laptops, and they glance down at the stream every couple of seconds to line up a shot or get their bearings. 1080p (or even 720) would be way overkill, and 60fps is also a waste of bandwidth.

As you pointed out, this also isn't a limitation of the cRIO or roboRIO. It isn't even a limitation of the FMS itself. It is effectively a limit of the WiFi router used on the field. If all six teams on the field are streaming 1080p video at 60fps, someone is going to start dropping control packets.

[sparkytwd]

Originally Posted by Tanis

Why do you need a higher quality video stream? You should be able to get much better quality than what you described and still be well within the 7 Mbps limit. I have yet to see a team that even noticed a difference in their video quality when they turned it down to get around 3 Mbps.

Most teams' video streams are about 2 square inches on their laptops, and they glance down at the stream every couple of seconds to line up a shot or get their bearings. 1080p (or even 720) would be way overkill, and 60fps is also a waste of bandwidth.

As you pointed out, this also isn't a limitation of the cRIO or roboRIO. It isn't even a limitation of the FMS itself. It is effectively a limit of the WiFi router used on the field. If all six teams on the field are streaming 1080p video at 60fps, someone is going to start dropping control packets.

You guys might be interested in ocupus. I'm finishing up a writeup of our competition this weekend with the sample video. With ocupus we stream an 800x448@30fps color and a 320x240@30fps infrared feed to our driverstation using only 2mbps. Reviewing our connection logs on the dashboard, showed only an average of 4 packets per match being dropped to the cRio.

[virtuald]

Originally Posted by sparkytwd

With ocupus we stream an 800x448@30fps color and a 320x240@30fps infrared feed to our driverstation using only 2mbps

This sounds pretty cool. It requires having an additional computer on the robot, correct?

[MrRoboSteve]

Originally Posted by Peter Johnson

For example, here's a tutorial on NI's website that installs PostgreSQL and uses it with LabVIEW on the Linux platform: https://decibel.ni.com/content/docs/DOC-30308

I will have to brush up on my PostgreSQL skills for helping at next year's regionals

[sparkytwd]

Originally Posted by virtuald

This sounds pretty cool. It requires having an additional computer on the robot, correct?

Correct, however one of my test platforms is the $65 Odroid-U3. With a PS3 eye cam, memory card and power converter you're looking at half the price of an Axis camera. #3574 uses the more powerful Odroid XU at $170. Under testing the performance edge it has over the U3 is only about 20%, and maybe even not that much. With 2 feeds, 1 of which is being processed by a hot goal detector, we barely break 50% utilization.

The only downsides I see against the Axis cameras are

1. Multiple components that need to be connected
2. No wpilib support

To bring it back to the thread at hand, I will be testing ocupus on RobotRIO in the hopes that it can support at least 1 low resolution USB camera without too much impact on other robotly duties.

[Greg McKaskle]

Speaking of USB cameras, the roboRIO has several USB host ports and there are UVC drivers installed. My testing has been through IMAQdx, the NI driver for camera buses such as USB. We've done testing with a variety of USB cameras, even some set up for stereo. We've also done a bit of testing with the industrial USB3 cameras running on the USB2 bus. Some of the mfg drivers are OK with this and it allows for higher end sensors, lenses, filters and the like. And of course IP cameras such as Axis also work. WPILib only supports Axis, but IMAQdx supports some others.

Greg McKaskle