Vision co-processor Location

[cad321]

Originally Posted by cpapplefamily

I'm going to give this a try. Solves two current issues. 1 no ethernet on Kangaroo. 2 using an IP camera, roborio, and co-proccessor with last year's radio. I say last year's because who knows what will be in store for us next year.

https://www.amazon.com/gp/aw/d/B00SA..._st_dp_summary

This actually looks like a great option to add a coprocessor such as the kangaroo, while being able to keep an IP camera. No need for a relativley heavy switch. According to amazon it only weighs 4oz. compared to a full size desktop switch, that are upwards of about 1lb normally.

[snekiam]

Originally Posted by cpapplefamily

I'm going to give this a try. Solves two current issues. 1 no ethernet on Kangaroo. 2 using an IP camera, roborio, and co-proccessor with last year's radio. I say last year's because who knows what will be in store for us next year.

https://www.amazon.com/gp/aw/d/B00SA..._st_dp_summary

This looks really cool, definitely helps with the weight problem. One reason I liked the switch system was it added the ability for a wired tether easily - especially this year, as our bot was cramped. We just added an ethernet pigtail to the switch, and mounted it in a convenient location. This was much easier for testing in the pits without wireless.

[cpapplefamily]

Originally Posted by snekiam

This looks really cool, definitely helps with the weight problem. One reason I liked the switch system was it added the ability for a wired tether easily - especially this year, as our bot was cramped. We just added an ethernet pigtail to the switch, and mounted it in a convenient location. This was much easier for testing in the pits without wireless.

yep need a three way.

[cpapplefamily]

Originally Posted by snekiam

We used this switch this year with no problems whatsoever. It is 5v, so just power it from the VRM.



A raspberry pi is 0.0683433 pounds. I do not see that putting you over the weight limit, and even if it did, shortening all your wires and zip ties would probably put you back under it. The switch does weigh a little more than the pi, but still not enough to really make a huge difference in your overall bot weight. Overall solution shouldn't be more than a pound.

Oh wow did we have troubles! We had our vision hardware working at home with:
TRENDnet 5-Port Unmanaged switch
UNITEK USB 3.0 to Dual Gigabit Ethernet Adapter
Kangaroo Mini PC Static IP 10.32.44.20 (Running GRIP)
Roborio mDNS
OM5P-AN Access Point Configured for Home use
Axis IP Camera Static IP 10.32.44.11
Driver station Obtain IP automatically

Connections
OM5P-AN Access Point Port 1(Nearest Power) -> Roborio
OM5P-AN Access Point Port 2 -> TRENDnet Port 2
Axis IP Camera -> TRENDnet Port 3
Kangaroo Mini PC -> UNITEK USB 3.0 port 1-> TRENDnet Port 4
UNITEK USB 3.0 port 1-> Driver Station

At home with the radio configured for home use wireless and tethered control of the robot worked and the Network tables updated with vision data

After plugging into the FTA radio configuration laptop for the Gitchi Gummi Get-Together 2016 all robot connections was lost to the driver station. Franticly hunting for solutions we could nolonger PING the Roborio so using a USB cable we opened the Roborio web page and found the network set to obtain the IP and the current IP was 169.abc.xyz.lmn (Something very wrong. We set the IP to static 10.32.44.44 to get things working. Still no communication with above configuration. We removed the Switch and Kangaroo using only the OM5P-AN Access Point to finally get Driver station to robot control.

Throughout the day we attempted to change the IP of the Kangaroo to 10.32.44.120 and found some Subnet Masks to be 255.255.0.0 and some to be 255.0.0.0. In the end Everything is set to static IP's and Subnet masks of 255.0.0.0. Other teams gave it a great try and the FTA at the event gave it a real good go too. He also helped us work through some extremely high packet trip issues that ended up being our Driver Station CPU usage. installed a New Laptop and Trip times cured we will have to go back to that one latter. Our FTA at this events gut feelings are our Roborio has a symptom some team have found but the FRC people have not discovered yet to why.

By the end of the event we had to unplug and plug the Ethernet cable to the Roborio each time we connected to the field. We had satisfactory control during our matches with a simple camera viewer on our smart dash board.

The frantic speed of this event I forgot many of the different things we had tried to get things back working. If any of you have suggestions to what we could look at please share. We will be poking away at it the next few days before we #1 reimage the Roborio, 2 configure the radio back to home use.
Remember all work before configuring for a the event.

[snekiam]

Originally Posted by cpapplefamily

Oh wow did we have troubles! We had our vision hardware working at home with:
TRENDnet 5-Port Unmanaged switch
UNITEK USB 3.0 to Dual Gigabit Ethernet Adapter
Kangaroo Mini PC Static IP 10.32.44.20 (Running GRIP)
Roborio mDNS
OM5P-AN Access Point Configured for Home use
Axis IP Camera Static IP 10.32.44.11
Driver station Obtain IP automatically

Connections
OM5P-AN Access Point Port 1(Nearest Power) -> Roborio
OM5P-AN Access Point Port 2 -> TRENDnet Port 2
Axis IP Camera -> TRENDnet Port 3
Kangaroo Mini PC -> UNITEK USB 3.0 port 1-> TRENDnet Port 4
UNITEK USB 3.0 port 1-> Driver Station

At home with the radio configured for home use wireless and tethered control of the robot worked and the Network tables updated with vision data

After plugging into the FTA radio configuration laptop for the Gitchi Gummi Get-Together 2016 all robot connections was lost to the driver station. Franticly hunting for solutions we could nolonger PING the Roborio so using a USB cable we opened the Roborio web page and found the network set to obtain the IP and the current IP was 169.abc.xyz.lmn (Something very wrong. We set the IP to static 10.32.44.44 to get things working. Still no communication with above configuration. We removed the Switch and Kangaroo using only the OM5P-AN Access Point to finally get Driver station to robot control.

Throughout the day we attempted to change the IP of the Kangaroo to 10.32.44.120 and found some Subnet Masks to be 255.255.0.0 and some to be 255.0.0.0. In the end Everything is set to static IP's and Subnet masks of 255.0.0.0. Other teams gave it a great try and the FTA at the event gave it a real good go too. He also helped us work through some extremely high packet trip issues that ended up being our Driver Station CPU usage. installed a New Laptop and Trip times cured we will have to go back to that one latter. Our FTA at this events gut feelings are our Roborio has a symptom some team have found but the FRC people have not discovered yet to why.

By the end of the event we had to unplug and plug the Ethernet cable to the Roborio each time we connected to the field. We had satisfactory control during our matches with a simple camera viewer on our smart dash board.

The frantic speed of this event I forgot many of the different things we had tried to get things back working. If any of you have suggestions to what we could look at please share. We will be poking away at it the next few days before we #1 reimage the Roborio, 2 configure the radio back to home use.
Remember all work before configuring for a the event.

We have never had mDNS working correctly for more than 5 minutes at a time - it doesn't seem to matter what laptop, radio, roborio, or even what code is on the roborio. It really sounds like something is royally messed up with your roborio - I would recommend reimaging it over USB. Unfortunately, there is not much actual FMS testing that can be done without being at an event. Can you ping the kangaroo PC from the driverstation when the roborio is unreachable? I would also recommend that you switch which port your roborio is plugged into - I believe it should be connected to the one labeled '802.3af POE' on the radio, or the one furthest from the power. Hope you get this figured out and working soon!

[cpapplefamily]

Originally Posted by snekiam

We have never had mDNS working correctly for more than 5 minutes at a time - it doesn't seem to matter what laptop, radio, roborio, or even what code is on the roborio. It really sounds like something is royally messed up with your roborio - I would recommend reimaging it over USB. Unfortunately, there is not much actual FMS testing that can be done without being at an event. Can you ping the kangaroo PC from the driverstation when the roborio is unreachable? I would also recommend that you switch which port your roborio is plugged into - I believe it should be connected to the one labeled '802.3af POE' on the radio, or the one furthest from the power. Hope you get this figured out and working soon!

We could ping the Kangaroo and even better Remote into it, we could also get a simple camera Viewer on our smart dash board. THE ISSUE was Roborio coms. This was tethered and in the pits never tested on the field.

Now the for the

MOST FRUSTRATING PART OF ROBOTICS

we are home wired as stated above and everything is working. Radio still flashed for FMS, Roborio unaltered. we just plugged the cables in turn on the bot and in record time it seemed connected to the driverstation ready to run.

[marshall]

Originally Posted by cpapplefamily

We could ping the Kangaroo and even better Remote into it, we could also get a simple camera Viewer on our smart dash board. THE ISSUE was Roborio coms. This was tethered and in the pits never tested on the field.

Now the for the

MOST FRUSTRATING PART OF ROBOTICS

we are home wired as stated above and everything is working. Radio still flashed for FMS, Roborio unaltered. we just plugged the cables in turn on the bot and in record time it seemed connected to the driverstation ready to run.

I've made comments about this before on Reddit or maybe on CD I think... FMS is a black box and is POORLY documented (Yes Virginia, I'm aware of the outdated FMS white paper). mDNS is unstable at best with FMS and on top of that no one seems to know how to correctly setup multiple devices on the team network as far as subnets and routing go.

I agree with you that this is frustrating. I worked with a couple of our students and we did our best to detail our competition setup from 2016 with a box and wire diagram in this paper: https://www.chiefdelphi.com/media/papers/3267

We gave up with mDNS very early in our testing and moved straight to hardcoded static IPs. Honestly, I'm not sure I would trust FMS with mDNS at this point even if it were thoroughly documented.

EDIT: Looking at our paper, I think one of our subnet masks is wrong. Will get that checked at some point. Like you I'm 90% certain we had to use different masks on different devices for some strange reason despite everything being in the same class C...

[adciv]

FYI, driverstation (and rio?) needs to be on 255.0.0.0 in order to communicate with FMS as the FMS is NOT on your class C. Also, the 169.X.Y.Z address in the pits is to be expected. 169 is the default IP class A when no DHCP server is detected. The radio does not contain a DHCP server but the FMS does. As such, in the pits the rio would self assign itself the 169 address.

On mDNS I got tired of dealing with the Windows 10 issues and just started hard coding the addresses even in the windows client tables. The issue seems to be Win 10 as the Win 7 & 8 machines work fine. No clue why other that "Blame Bill Gates".

[marshall]

Originally Posted by adciv

On mDNS I got tired of dealing with the Windows 10 issues and just started hard coding the addresses even in the windows client tables. The issue seems to be Win 10 as the Win 7 & 8 machines work fine. No clue why other that "Blame Bill Gates".

No, there were issues on Raspberry Pis, on Jetsons, on Laptops running Linux, and on OS X. mDNS on the FMS system did not work as advertised for a lot of teams in many different situations from what I saw at districts and in the myriad of questions I got throughout build season.

Good to know about the netmask on the DS.

[cpapplefamily]

lots of great discussion here. Can't wait to read your paper. Some new interesting points that have been mentioned and I didn't inclued. The Kangaroo is Windows 10 home, DiverStation Windows 7 Professional (tried both a 32 and 64 bit)

[cprofitt]

Our team used a RasPi, openCV and network tables.

The RasPi using compiled openCV did the vision processing and just updated the distance variable in network tables.

[Jon Stratis]

Originally Posted by cpapplefamily

I been testing some vision using a second laptop on the network wifi running Grip and has been the most successful experience. I tried on roborio and on the driverstation of runing GRIP with undesirable results. So tonight I ordered a Kangaroo mini PC. I wonder do we need to put a network switch on the robot with the Kangaroo or can we install the switch and Kangaroo on the driverstation table. I like the switch and kangaroo on the driverstation table is there reason not to do this? I figured that to be FRC event legal it can't be wifi.

As I haven't seen anyone else mention it, check out R93 in the 2016 rulebook:

3 Devices hosting the Driver Station software must only interface with the Field Management System (FMS) via the Ethernet cable provided at the PLAYER STATION (e.g. not through a switch). Teams may connect the FIELD Ethernet cable to their Driver Station device directly via an Ethernet pigtail, or with a single-port Ethernet converter (e.g. docking station, USB-Ethernet converter, Thunderbolt-Ethernet converter, etc.).The Ethernet port on the OPERATOR CONSOLE must be easily and quickly accessible.

That one rule makes putting something like this on the driver station much more difficult. The ethernet from the field has to go straight to the driver station laptop, and then you have to go from that laptop to the secondary vision processor - so you have to get the laptop to act as a pass-through for the data you want.

All in all, it's much easier/better to put it on-board the robot.

[cpapplefamily]

We have abandoned the switch idea and been testing on bot but thanks for pointing out the rule. It helps for future tests.