If you had 2 cameras each detect the same object you could do find the distance to the object. If you had the size of the object in the image you could find the distance. Both of these are fully possible with the pixy.
And yes pixycams use a very simple and naive system for object detection. They do that because its the only system they could package into any reasonable size.
If you didn’t know where it was that would be a bit tricky. It should be too difficult to find distance from 1 camera on a plane with a constant size object.
they were all posted within a minute of each other. Jpearman was like an “oh yeah btw we got this website” and kent’s was a “lol, i was just about to post that” so i suppose DRow’s is more official so to say
Something that I don’t really feel is clear - will the current blue 7.2v batteries also be used with V5? Or will there be new “big” batteries?
Other things -
Big thumbs up on RJ11 motor wiring. I can get rid of my soldering iron. I hope you designed the RJ11 socket catch to be quite robust.
I had really hoped that the motors would support a through-axle design.
Program upload to the V5 brain hasn’t been discussed - is there anything like the orange programming kit built-in? Or will it still be via attached cable?
Paul stated in the other thread that the 6-32 screws will no longer be required. I assume he means only for the motors, unless they redesign the rack gears (which use 6-32)?0
Any thoughts on adding an electrical actuator component that gives 1-2" of travel?
My student asks: Does the new controller have accelerometer?
(Cortex had one, you could drive a robot by tilting the controller. Or implement gestures…)
I have a question on port usage and compatibility.
The render and spec shows 21 new RJ11 ports. Those are all 4-pin power+digital comms.
Then, there are only 8 cortex-like ports.
Given the announced compatibility with older sensors, I suspect the cortex ports could be used in one of 3 modes as PWM, analog input or digital I/O.
But 8 ports isn’t much. If you’s still like to use quad encoders on undriven wheels for dead-reckoning, gyro, some pots for absolute positioning and a bumper, you’re out of ports.
This, together with waaaay more RJ11 ports than the motor allocation (and a constant grief over outdated->overpriced VEX gyro, for example) suggests that besides the compatibility with current sensors, there will be new, perhaps smart, V5 sensors.
V5 gyro (may I say full IMU?) would make sense, but bumper, pot, LED? Not so sure about those.
So let me voice this: What I really value on VEX Cortex is the least possible level of abstraction. For a bumber, you use a GPIO. Fot a pot, A/D converter input. Even for gyro, you can use raw A/D and implement the rate integration all yourself. No need to apply a full ISO/OSI model just to read a simple sensor input.
It prepares the students to understand real embedded systems, MCU applications. I hope this won’t get lost in V5.
And for the actual question(s):
What V5 sensors should we expect?
Would “smart ports” have a simple digital/analog mode as well (perhaps using passive adapters)?
Many of our upgrade decisions will be based on changes to the PLTW kit. Of course our competition teams will change, but updating a whole district will be based on the curriculum available.
Is that a planetary gear drive in the motor, that allows a “cartridge” swap out of the gear ratio’s?
If so, I wonder if it has an ID to tell the motor controller what gear ratio has been installed?
Will be nice to see next week at CES.
Edit: answered my own question, on the V5 page it describes the colored portion of the gearbox that you can see through the viewing window. Definitely helps teams know what’s going on, very nice. Not seeing the auto-identify for the controller though?
Although the ports look like IQ from a mechanical standpoint, I would imagine the signaling isn’t I2C this time around, maybe RS485 to deal with noise and distance?