On Board Computer
 

I have seen some teams mount min itx computer on their robots. I would like to know how you would hook it up and what are some of the uses of one.

Re: On Board Computer
 

We used it for image processing this year. We had a Kinect plugged into the onboard PC (consisting of a Zotac ITX motherboard with a dual-core Atom 330 and an SSD), image data was sent back to an applet running on the driver station where the driver could line up the target, get the distance, and then the wheel speed for the shooter would be calculated. Some teams did great image processing by using the Axis camera and doing all the processing on the driver station, but there certainly are some nice benefits to doing it all on the robot (one of them being that you can use the Kinect on the robot) and we hope to improve our system in the future as well.

Re: On Board Computer
 

Thanks. But how did you power it? Did you use a pc power supple connected to the pd board or something else?

Re: On Board Computer
 

The simplest way to power an onboard PC would be with a DC/DC PicoPSU. It's much lighter and smaller than a standard PSU.

Here's one you could use.

http://www.mini-box.com/picoPSU-150-XT

It attaches above the motherboard's 24 pin socket. You would then strip the leads that are meant to go to an AC converter (laptop power brick) and plug those into a 12v on the NI PD Board. Simple as that.

Re: On Board Computer
 

thanks

Re: On Board Computer
 

The Zotac board that we used (http://www.zotacusa.com/zotac-ion-it...onitx-t-u.html) accepted a 19volt input so we just got a 12 to 19 volt power supply, very clean setup. Avoids dealing with the 24 pin atx connector to begin with

Re: On Board Computer
 

Is a board like this also a viable idea? Our team was thinking about building an onboard computer, and we wanted to keep things on the cheap. There is a $400 limit after all.

Also, will there be any problems with bootup time? The last thing I want is to turn our robot on, and have the FTA giving our team weird looks every match because windoze is taking it's sweet time.

Re: On Board Computer
 

You could always just do your image processing on your C-rio? I believe we did that and didn't have a problem but your just have to have like absolutely as much off load on the cpu on board so that the cpu can actually do it. This resorted to us using 2CAN and integrated PID loops on the Jaguars them selves.

Re: On Board Computer
 

thanks for the suggestion but in I think I would go with a mini itx board to keep space down

Re: On Board Computer
 

about the role of keeping each part under $400 does this mean keeping the combined total of the cpu motherboard ssd and ram under $400 or keeping each part under the limit

Re: On Board Computer
 

Our total was under $400 I recall, just the Zotac board + RAM + SSD should keep you under $400 no problem (and I'm pretty sure it would be counted each party individually anyway but I'm not completely sure).

Bootup time is very fast, under 30 seconds with an SSD, so plenty of time from when the FTAs have you power up the robot to when it's situated on the field ready to go.

IMHO you definitely want to go for a low-power, compact solution like Atom.

Re: On Board Computer
 

what os are you running? and what's the tdp of the atom

Re: On Board Computer
 

The pico itx power supply that was linked probably is not a good choice. It is not designed for voltage drops like those that can happen on a robot. The same company makes the m3 model that can take drops down to 6 volts.

Re: On Board Computer
 

Thanks!

Re: On Board Computer
 

one more thing how do you control the program owns you are running?

Re: On Board Computer
 

We ran Ubuntu on ours. I want to say the TDP of the Atom itself is like 13W but I'd have to check, it's very low.

We had the server side launch on startup so it was running when the robot was powered up.

Re: On Board Computer
 

We used a Pandaboard running Ubuntu. It runs on 5V, 2A so under 10W. We set up a user that auto-logs in on startup and then launched our program in that user's .profile file. We're working on a paper that describes everything in detail, hopefully it won't take too much longer.

Re: On Board Computer
 

Hope to see the paper soon

Re: On Board Computer
 

That's not necessarily true. Reconsider how you perform your image processing. It's perfectly reasonable to process a single frame to get all the information you need to lock on to the target and shoot accurately.

Vision processing does not necessarily mean processing vision in real-time, at real-time speeds. That is a mistake many programmers make. In fact, I can tell you that most manufacturing vision systems we have in our production lines use the single-frame method.

Re: On Board Computer
 

Yup. We grabbed one frame, processed it in about 100ms, then fed the result into a control loop using the gyro. We were even able to pull out our lateral position on the field to shoot off center if we were on the side of the key, allowing us to have an accurate alliance bridge autonomous mode. We did this spending 0 dollars and 0 hours on an external computer.

Re: On Board Computer
 

That's exactly what we did except we fed turret position. The cRIO CPU would spike to around 80-90% for a moment during the image processing but since nothing else was happening during the shot sequence it was never an issue. Never saw the need for continuous image processing or offloading to an external CPU...

Re: On Board Computer
 

I'l like to elaborate on my last post a bit. We did run the vision code continuously, but the control loops only relied on one valid frame and the vision processing ran in a separate task with lower priority than the main robot code/communications task. The vision task slept enough to not cause particularly high CPU usage. When we were looking for a frame, we would use the last processed frame (if we got a good result within the last, say, 100ms) or wait for a fresh result to appear.

Re: On Board Computer
 

Just to make sure I understand this... on a separate low priority thread you were continuously grabbing the latest image, thresholding, filtering, calculating distance/angle/position then sleeping for a bit. Then whenever your shooter pressed the shoot button you would check to make sure a valid calculation was made within the last 100ms or so and then use the last calculated distance/angle/position to align the robot and spool up the shooter wheel?

If the image processing was only taking 100ms what was the advantage of running it continuously? Was the image quality degraded because the robot may have been still moving?

Re: On Board Computer
 

We did a bit of the opposite. Our vision acquisition and processing didn't run unless the 'fire' trigger was pulled. Then, once it gathered the first valid image and had a target, it saved those values to reference against our turrent pot and shut down the vision code.

We'd see a temporary spike to 90% during the one frame acquisition and processing, but usually our code hovered around 70-75% cpu.

Re: On Board Computer
 

Yes, for a few reasons.

First off, we didn't want to block the control code. While most control loops ran in their own threads, there were still some things that were 'close' to time dependent in the main thread. Also, doing this made it easier to debug as we could stop the robot at any point and look at what it thought about the target. This allowed us to use the vision system to align the robot for autonomous mode without any additional glue code. The cost of running it all the time vs. one shot at a time is pretty minimal, and this is just the way we chose to implement it.

Re: On Board Computer
 

Thanks for info. We are using the Java command based framework and it seemed more natural to do the single frame analysis when required but I like the idea of not blocking and keeping everything running at a steady pace. We had one connection issue on our first practice match of the season that I'm pretty sure was because the cRIO spiked at 100% CPU during an image processing step. We cleaned up the code and made it more efficient and never had that issue again but it was always in the back of my mind.

Re: On Board Computer
 

My bad, Btslaser knows more about this then i do. We did do a frame method instead of real time processing.

Re: On Board Computer
 

We're about to give it a try. We found the cRIO and our driver station computer to be lacking. It seems that the network camera acquisition is terribly inefficient. Using a USB webcam uses much less CPU. Anyway, we're building to use this for a few years.

Intel Core i7-3770S Ivy Bridge 3.1GHz (3.9GHz Turbo) LGA 1155 65W Quad Core Desktop Processor Intel HD Graphics 4000
4GB DDR3 1600MHz G.SKILL Rimjaws Series
64GB Crucial M4 SSD
COOLER MASTER Hyper 212 Plus 120mm Heatsink (for 120mm fam compatibility)
Intel BOXDH77DF LGA 1155 Intel H77 HDMI SATA 6Gb/s USB 3.0 Mini ITX Intel Motherboard
M2-ATX Power Supplu from Mini-box.com

I think we're going to attempt a custom made enclosure unless someone has a lightweight mini-ITX case they would recommend.

This will also be our primary programming computer where we'll remote in to program the cRIO.

A bit overkill for everything, but it should last for a few years.

Re: On Board Computer
 

Every mini-itx cases I've looked at, even the ones advertised as aluminum, are still listed by their manufacturer as being 2 to 3 pounds for the chassis. What kind of weight allowance are you looking for?

Question: Would it before more effective to get a tablet to handle the processing?

Re: On Board Computer
 

I would be afraid of a tablet for a couple of reasons...

Usually, performance wise, they suck. To keep the costs down, manufacturers cut down the core performance in order to allow the use of the touch screen and the associated hardware and hinges needed.

Even though the costs are lowered by the performance hit, they're still too expensive, and fall way above the $400 price tag for single COTS item [R41]. By building your own PC, you can get every part (and really nice parts might I add) for less than $400 each.

Find a decent performing, sub $400 tablet and I might be interested. My main interest is to keep the platform in Windows 7, and use LabVIEW (FRC version) to keep the learning curve down, while also allowing us to have much more capability.

By having the PC onboard the robot, not only can we offload vision processing, but we can drop off some of our closed loop controls to the PC to improve responsiveness as long as we keep the network threshold below 100Mbits (Robot LAN), which I cannot see being an issue for a LONG time.

Re: On Board Computer
 

The reason I asked about a tablet is the first generation transformer from Asus is now under $350 from most online vendors.

From its spec sheet you get a dual core Tegra 2 processor (1 GHz), 1 GB of DDR 2 memory, 16 GB of onboard memory, and weighs in at 1.5 pounds.

Re: On Board Computer
 

I would be sold on using an on-board computer, if someone could solve the problem of turning off the robot.

This is the scenario. After the match ends, volunteers urge you to hurry off the field, and you push the main breaker, killing the power to the your Windows 7 PC.

I've always been told to not unplug a computer unless all else has failed. I've also seen devices (robot controllers, phones, tablets, computers) corrupt themselves when there was a loss of power. Would there be any damage to the computer (hardware failure, software corruption)? More importantly, is there anyway to safely shut the computer down before cutting the power?

Re: On Board Computer
 

We talk about that subject for a linux computer in a paper we just posted:

http://www.chiefdelphi.com/forums/sh...hreadid=106634

In windows, part of the solution is to have the program on your second computer execute the command "shutdown.exe /s". You need to trigger that somehow though.

Re: On Board Computer
 

Here's how I would do it...

Whenever the finish VI is called, send a UDP packet to the PC that has a command to tell the PC to shutdown (gracefully). I already have it working actually.

Since I'm using LabVIEW, I have it set to call the command line function "shutdown -s -t 5" which gives LabVIEW a few seconds to end gracefully. Right after this call, I have a Quit function which will suspend all of LabVIEW, then will shut down the PC normally. By keeping the system cleaned and optimized (with SSD and i7 nonetheless), it only takes a matter of seconds to shutdown, plenty of time for you to casually walk to your robot on the field and shut it down.

There is also a choice of using the NI Real Time Operating System, which I believe our license has access to. It's designed to be able to turn off immediately if needed. It just runs a single program from the disk. The only faults would be if you're reading and writing data to the HD.

Re: On Board Computer
 

Does the finish VI actually get called at the end of a real match? I was under the impression that it just returned to the teleop disabled vi. Please correct me if I'm wrong.

Re: On Board Computer
 

Hmm... good point. I think you're correct. The Finish VI is only called when you push the Finish button on the Robot Main VI, isn't it...

Well back to the drawing board...

Re: On Board Computer
 

This year, my team had lights on our robot, that we wanted to do something specific at the end of the match. I believe we put the command in Disabled, and added some logic to only use the command on the third time disabled is called (once at beginning of match, once after auto, once at the end).

Re: On Board Computer
 

I'm not an LV programmer but I have had to work with it a little for FRC. I would put a variable in called something like teleopRan and initialize it to False. Then when teleop starts you can set it to True, then when Teleop Disabled is run have a if that checks if teleopRan is true and match time is greater than say... 119 seconds (so if it disconnects on the field it doesn't turn off the computer in case it reconnects) then shut off the computer. You'll want to test this with practice mode obviously.

- Oliver

Re: On Board Computer
 

We used a netbook on the robot this year. The easy way to fix the shutdown problem is not to have to shut it down at all. You are allowed to use the netbook with it's normal battery. Just make sure the software in the netbook and cRIO is smart enough to realize that one or the other might be off. As the netbook (with SSD) was mounted to withstand being smashed over the 6" bump in the field moving it off the field shouldn't create more shock unless you drop it.

Re: On Board Computer
 

Something I Just came across: http://www.engadget.com/2012/06/01/r...nd-tinker-toy/

$35.. hard to beat but not sure about the computing power it has.

Re: On Board Computer
 

The Raspberry Pi is quite nice. It's mostly attractive because of it's cost it's hardware is not really unique. However, actually ordering one is a real challenge. I got one but I could have made 100 of them in the time it took and now I'm on their waiting list again.