|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: APC on Robot
Quote:
In fact, I'd be willing to bet that our vision setup (processing on the ds laptop) has way less lag than your onboard processor. The ds laptop is an order of magnitude faster than an onboard processor, and the time from an image being sent from the robot to the laptop, the laptop processing it, and the laptop sending the coordinates of the target to the robot, was well under 100 ms all the time. If you use a PID loop for alignment, you can compensate for any lag pretty easily while sacrificing response time. When we used vision, we could align our robot with the target in under 1 second every single time. Also, watch videos from 341 in 2012. They were one of the fastest to get aligned, and they processed images on their driver station laptop. If you think that this process could be improved with lower lag, then prove it. You can say (and be right) that a hardwired connection will be faster than the wi-fi connection, but unless you've actually done tests with well-written and complete setups in both arrangement, you can't comment on the effect of the increased time on the effectiveness of actual image processing. What you have above is just speculation with incorrect information. Last edited by magnets : 16-10-2013 at 16:20. Reason: typos |
|
#2
|
||||
|
||||
|
Re: APC on Robot
You'll easily get the framerate. That is based off connection speed. However, even if you get a lower processing framerate onboard the robot, 3 fps is good enough to outmatch the driver station at times. Then, the computer will need to process those images and then send data back to the cRIO. You can use UDP if you are trying for speed, but there is no error correction so there is a chance your robot could do something stupid.
If the robot was having vision tracking making sure it doesn't bump into anything, the robot is speeding at top speed and you walk in front of the robot (accidentally), running on the driver station with a .5s delay with everything, the robot will have a minimum of 5 meters to start reacting, not including the braking distance and other factors. However, having the processing on the robot speeds things up a lot. Plus, you have the lag increase when you go farther from the AP/Laptop in the first example. |
|
#3
|
||||
|
||||
|
Re: APC on Robot
Quote:
At competition, the our total delay for the transfer of both the image and the processing was ALWAYS less than 100 ms, usually less than 50ms. You don't have evidence that shows the total response time from either of the setups, and you also don't have any evidence of how response times actually effect the robot's ability to function. Before making your decision, I strongly suggest you test both methods! (Also, if your robot can travel 5 meters in 0.5 seconds, you're going 32 feet per second, more than triple what you normally see in FRC). |
|
#4
|
||||
|
||||
|
Re: APC on Robot
I'm not going to argue with you, but if you are driving at a high speed, as you go farther from the access point, the robot will get a slower and slower speed. Also, if you want the robot to be semiautonomous, it isn't possible to use wifi because every millisecond counts because there are so many variables to calculate a trajectory and make sure the robot follow it in a closed-loop code. You must be the world's best programmer is you can do that. Things like a rotating turret could easily use network because you have the time to make these measurements.
|
|
#5
|
||||
|
||||
|
Re: APC on Robot
I'm not going to argue with you, but if you are driving at a high speed, as you go farther from the access point, the robot will get a slower and slower speed. Also, if you want the robot to be semiautonomous, it isn't possible to use wifi because every millisecond counts because there are so many variables to calculate a trajectory and make sure the robot follow it in a closed-loop code. You must be the world's best programmer is you can do that. Things like a rotating turret could easily use network because you have the time to make these measurements. I will have to agree that using network can relieve many electrical hardships because you do not have to worry about a separate computer psu (regulator and shutdown watchdog). Also, depending on the board you are using, using an interface like i2C can be difficult. For the APC, it seems just like the RPi, which is quite simplistic. Other than that, you would typically like to have the ability to code/mess with the code, so you will need to do some work into integrating either a web interface or rdp forwarding, etc.
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|