hello, I’m trying to test out photonvision for apriltags and I am unable to connect to the dashboard. I have flashed the pi with the latest release with Balena Etcher, I start up the pi then I try to connect to the dashboard and it wont connect. I have the pi and the computer plugged into a network switch, and I have tried reflashing the pi a few times and that hasn’t worked, anyone know why I cant connect, am I missing a step or something?
Some things to check:
- Does the pi have a stable power source?
- I’ve ran into issues when the pi goes straight ethernet into a windows computer so instead plugging it into robot network switch (with radio) or even home wifi router works
the power source should be stable, earlier when I was trying to use wpilibpi it worked perfectly, I have it plugged into a network switch and not directly into the computer
If its Computer → network switch → pi I think thats the same thing
Try:
- connecting pi to wifi router and wirelessly connecting to router with computer
- connecting pi to robot radio and wireless connecting computer to it
IIRC this is a known problem people have had
Also use angry ip scanner to see if anything comes up ip wise.
2 Likes
If there is no router on the network, no devices will have any way to get an IP.
@Kadd you will need to add a router to this network. A robot radio will work well.
3 Likes
If you can’t easily get a robot radio or something else to resolve names maybe you have a display you can plug into the RPi. Then you’ll know the ip address to use. That’s the recommended way to access devices on the robot anyway. If using the IP address isn’t the problem, you can move onto the next troubleshooting step.
This may be your problem
A minor nitpick, but the presence of a router is irrelevant. What’s needed is a DHCP server, which is a feature commonly provided by consumer-grade routers. This is the system that hands out IP addresses. Without it, each device will use a feature known as APIPA to automatically assign an IP address in the 169.254.X.Y range. This ensures all devices on the same network segment can talk to each other, albeit with seemingly random IPs so good luck figuring it out (this is why mDNS hostnames like protonvision.local still (sometimes) work even without the robot radio connected)
1 Like
I’m fully aware the real requirement is a DHCP server. But I’m not about to start suggesting users find some shareware one online and try to configure it themselves.
I’ve also found link-local addressing (APIPA) to be flaky at best, and won’t recommend it either.
The lowest-friction route for 99% of users is to ensure they are on a network with a router.
1 Like
I think you may have misread my comment. I was simply pointing out the distinction between a router (as a piece of networking functionality) and a DHCP server. I didn’t mean to imply that anyone should just go run a dhcp server on a Pi or something on the network. I also was describing APIPA’S functionality and that it SHOULD work, not claiming it’s 100% reliable.
Again, it was simply a minor nitpick on your use of the term router, not advice on how to resolve the issues OP is having. I have no doubt you and others understand how various network components work and did not intend for that to come across as a lecture. If anything I said previously was received any differently, I apologize.
1 Like
If you would not mind explaining further, what does APIPA have to do with the *.local names working sometimes? I thought the NI hacked up version of Bonjour that we have to install on the driver-station PC with the other stuff each year was supposed to do name resolution especially since I found the statement below on the Internet. My PC used to be able to resolve names without a robot radio but it no longer can. Your statement intrigues me.
"While APIPA provides Windows clients a usable IP address, it does not provide the client with nameserver (DNS or WINS) and network gateway addresses as DHCP does.
And the solution to repair the network reposted above in number 8 totally baffles me as to how that can make name resolution work.
And I do appreciate your more rigorous definitions and explanations. For years I thought network hubs and switches were the same thing. Recently my desired home configuration to include the roboRIO, RPi, LimeLight, etc. wouldn’t work. My team network guru explained that I was using a hub but needed a switch which I did happen to have in my junk box. Thanks.
In short, nothing. APIPA is a mechanism for auto-assigning IP addresses in a well-known range to allow devices to communicate with each other at the network layer of the OSI model. DNS functions at a higher level and allows dynamic resolution of human-readable names to IP addresses.
Multicast DNS (mDNS) is another protocol for name resolution and functions in parallel to DNS, but “above” the network layer. Both will get you (or more specifically whatever process is asking) the IP address of a remote machine, albeit through different mechanisms.
Both Bonjour (from Apple) and NImDNSResponder.exe (from NI) are mDNS clients that handle the translation from OS system calls (I want to talk to xyz.local) to mDNS protocol messages on the network (and responds when other machines make similar requests).
I THINK that answers your question. If not, please feel free to ask more questions or DM me so we don’t get too far off the rails on this thread. I’m far from an expert though, so I’m just waiting to be corrected myself 
1 Like
btw this worked, thank you.