BASKETBALL · ROBOTICS · CUSTOM CHIPS · VIGO
When I practise shooting from beyond the three-point line, I sometimes have to walk a considerable distance to recover the ball, especially when it hits the rim and rebounds in the wrong direction. I have been thinking about a robot that could collect it and return it to me, so that I can keep shooting. But suppose I also want to make a custom chip for the robot. Would it be useful, or would I only be complicating the project?
In a previous post I discussed a robot that would collect the balls after my shots
First, Collect My MissesThe practical reason for a robot at shooting practice: getting the next ball back.. Now I want to examine how the electronics could work in a humanoid robot of 1.69 metres. The robot would collect the ball after I missed a shot or scored a basket, and would send it back to the player waiting some distance from the hoop. I do not need it to tell me whether I have shot well or badly. Returning the ball would be enough for the moment.
WATCH · 70 SECONDS
A photonic chip: one possible future route
The robot still needs electronics. The video below explores an additional possibility: a custom photonic chip, which guides light through microscopic structures. Such a chip can handle optical functions alongside electronic circuits. It would not simply replace the FPGA described later, or become the robot's complete brain.[1]
The sequence moves from design and wafer processing to testing and packaging. These are real stages in photonic-chip development, although the film compresses them and simplifies the equipment.[1] Connecting optical fibres accurately and testing the optical path are important parts of photonic assembly.[2]
For this robot, I would first need to identify a useful optical function—for example, a link carrying sensor data—and compare the complete system with an electronic alternative. Light sources, drivers, detectors and the interface to the controller also count towards cost and energy use. The basketball on the lid gives it an identity. It does not improve its timing.
That leaves us with the practical question behind the video: what does the robot actually need? I would begin with its task, then decide whether ordinary electronics, a custom digital circuit or a photonic component could help.
First, what the robot has to do
The robot that I imagine would have a compact body, electric joints, cameras and hands capable of holding a basketball. These components are not science fiction. There are already humanoid robots with articulated hands, cameras and batteries inside their bodies. Of course, that does not mean that any of them can do what I am proposing. The height of 1.69 metres is a condition of my design, not the measurement of a robot that I have constructed.[3]
At first I would not try to make it jump. Both feet could remain on the floor. Imagine that I shoot from a fixed place beyond the three-point line. The robot looks for the ball, picks it up, checks that I am ready and makes a controlled pass with both hands. If the ball rolls away, it will have to walk towards it. And if another person gets in its way, it must stop and wait.
I think it would be better to develop this in several stages. First, put a stationary ball in front of the robot and make it return the ball with a short pass. Then increase the distance. After that, try with a ball rolling on the floor. Only when the hands, the balance and the control system work satisfactorily would I try catching a low rebound with a reasonably predictable trajectory. Catching a ball in the air is more complicated than picking it up from the ground, so there is no need to begin with the most difficult test.
The final objective would be to repeat the complete operation: pick up or catch the ball, hold it securely, locate the shooter and return it with enough accuracy. Perhaps the best solution would sometimes be a bounce pass. But that would also have to be tested. The speed of the pass, the point where the ball should bounce and the distance to the player must be determined on a real court, with the real robot. We cannot suppose that a slow-looking pass is automatically safe.
Do we need to manufacture a chip?
We should distinguish between three things. We can design a circuit board adapted to our robot, using ordinary processors, sensors and motor drivers. We can also use an FPGA, which is an existing chip whose internal digital circuit can be reprogrammed. Or we can design an ASIC, in which our circuit is manufactured permanently in silicon. All three could be called custom electronics, but they are not the same. In my opinion, it would be a mistake to manufacture an ASIC simply because having our own chip seems more advanced.[4]
| Option | What we would adapt | Why I would use it |
|---|---|---|
| Custom board | The connections, interfaces and arrangement of standard components. | Construct the first prototype and measure its behaviour. |
| FPGA | The digital logic programmed inside a reconfigurable chip. | Test a special-purpose circuit and make changes when necessary. |
| ASIC | A fixed circuit designed and manufactured in silicon. | Only when the final design is stable and measurements justify fabrication. |
My first choice would be to use commercially available processors and other components. I would measure how they perform and, if I found a particular operation that could be improved, I could try implementing it in an FPGA. This is also a way of testing a design before manufacturing an ASIC. If the first version of the circuit does not work as expected, an FPGA allows us to modify it without having to manufacture another silicon chip.[5]
What function could the custom chip perform?
For example, I would consider a circuit that deals with the timing of the information received by the robot. The camera and its vision processor would identify the ball in successive images. The proposed circuit would receive the ball detections together with the time at which each image was captured. It would combine these observations with the necessary movement data from other sensors, calculate an updated estimate of the ball's trajectory and warn when information is missing or too old.
The movement controller could then use this estimate to decide whether the robot can still catch the ball. I would not give the chip direct control of the fingers, nor would it replace the system responsible for keeping the robot balanced. And there is another limitation: if a person passes between the camera and the ball, a faster chip cannot see through that person. We still have a problem of perception.
Possible distribution of functions. I would also include an independent supervisory stop system capable of overriding movement. The custom circuit must not be the only safety protection.
Let us see why processing time might be important. Suppose the ball moves at 6 metres per second. In 60 milliseconds it travels 36 centimetres, while in 15 milliseconds it travels only 9 centimetres. The difference is 27 centimetres. That is enough for the robot's hands to be in the wrong position when the ball arrives. I am using these figures only as a numerical example, not as measurements obtained from a robot or as a claim about what the custom chip would achieve.
However, what happens if the delay is not caused by the processor? Perhaps the camera takes too long to capture the image, the images are waiting in a queue, the calibration is inaccurate or the shoulder joint responds slowly. In any of these cases, making the calculation faster might hardly improve the catch. For this reason I would measure the time from the moment the image is captured until the robot actually moves, and only then decide which part needs to be redesigned.
The steps I would follow to manufacture a custom chip
- Measure the original system. Record when the sensors capture information, how long it takes to process it, the errors in the estimated position of the ball and when the movement controller responds. I would begin with the hardware that already exists.
- Define exactly what the circuit must do. Specify its inputs and outputs, the numerical precision it needs and what it should do when sensor measurements are delayed, arrive in the wrong order or do not arrive at all.
- Describe the circuit and simulate it. Write a hardware description and test it using the recorded sequences. I would also check arithmetic overflow, measurement units, reset behaviour and the boundaries between clock domains, not only whether the robot catches an ordinary ball.
- Try it on an FPGA. Compare errors, processing delays, variations in those delays and electrical power with the original solution. A better average time would not be enough if the new circuit sometimes produced exceptionally long delays.
- Consider making the ASIC. Only if the circuit has become stable and useful would I proceed to synthesis, physical layout, timing verification, manufacturing checks, fabrication, packaging and testing of the real chips. This requires specialised tools, foundry-compatible processes and people with experience in chip design.[6]
There are projects such as Tiny Tapeout that make it possible to participate in the fabrication of small experimental chips. We could, for example, use something like this to learn how to manufacture a limited timing circuit. But a small educational chip is not a complete control system for a humanoid. We would still have to consider its connections to the rest of the electronics, fabrication limitations and delivery times.[7]
Testing it on the basketball court
I would not test the chip in isolation and then conclude that the robot has improved. First I would compare the two electronic solutions using the same recorded sensor data. After that I would carry out controlled tests with the physical robot on a basketball court. Otherwise, perhaps the second test would give better results only because the camera was in a more favourable position. Or worse results for the opposite reason. In neither case would that tell us very much about the chip.
This is related to something I discussed in another article about keeping the whole relevant action in frame
First, Keep the Play in FrameWhy the original view matters when checking an automated explanation.. To know what happened, the video should show the ball, the hands and feet of the robot and the person receiving the pass. A close-up of the processor might look interesting, but it would not show whether the ball was returned to the right place.
| What do we want to know? | What should we record? |
|---|---|
| Can it hold the ball? | Successful pickups and catches, failed attempts, slips and the conditions of each test. |
| Does it return the ball correctly? | Where the pass lands or is received, the ball speed and whether the player indicated readiness. |
| How does it respond to uncertainty? | What happens with an obstructed camera, missing images or people entering the work area. |
| Does the custom circuit improve anything? | Distribution of delays, ball-tracking errors and computing energy, with motor consumption measured separately. |
There is also the question of whether the robot really needs to be humanoid. Legs and articulated hands make it more interesting, but they introduce difficulties that a simpler mechanism for collecting balls might avoid. Something similar happens with energy consumption. Even if the chip consumes less electricity, that does not necessarily mean that the battery will last much longer, because walking and moving the arms also require energy. Both the humanoid design and the custom chip should demonstrate an advantage in practice.
Some improvements for the future
One improvement I would like to try concerns the hands. It is not enough for the robot to reach the ball at the right moment. It must also hold it without letting it slip or squeezing it unnecessarily. I would compare different soft contact surfaces and perhaps add force sensors to the fingers. If most failures are caused by the grip, putting a faster chip in the robot will not solve them.
Another possibility would be to use a fixed camera covering part of the court, in addition to the cameras on the robot. Imagine that somebody crosses in front of it just as the ball rebounds. A second view might help, although we would also have to calibrate both views and synchronise their measurements. I would not add this complication unless the first tests showed that the robot was losing the ball too often.
I would also establish a simple comparison between versions. For example, make 50 attempts under the same conditions, first with the ordinary electronics and then with the FPGA. We would count successful recoveries and return passes, the errors, unexpected stops, energy consumed per returned ball and the longest processing delays, not just the average. Fifty attempts would only be an initial experiment, but at least we would begin to distinguish an improvement from a favourable demonstration.
The photonic option shown near the beginning belongs to this later stage of development. I would investigate it only after identifying a function that could benefit and comparing it with an electronic solution. Calling a chip photonic does not make the robot catch the ball any better.
Imitation, competition and the scapegoat
There is another question that I find interesting. Why do we sometimes want to develop a particular technology? Perhaps we have seen another company designing its own chips and we want to do the same. The idea of mimetic desire concerns the influence that other people, who serve as models, can have on what we wish to achieve. This can also include the prestige associated with making something. Nevertheless, using a technique developed by others does not necessarily mean that we are competing with them.[8]
For example, we could say: "I want to try this circuit because it may reduce a delay that I have measured." That is an engineering reason. But if we say: "Other teams manufacture their own chips, so we also have to manufacture one," we are beginning with a comparison of status. It is possible that the two motivations exist at the same time. I think it is useful to recognise this instead of supposing that all our ideas have appeared independently of what other people are doing.
But is a scapegoat necessary? I do not think so. Scapegoating is another mechanism described in mimetic theory. It occurs when the members of a group direct their conflicts towards a person or another group, whom they consider responsible for their problems. But not every imitation produces this situation, and imitating a useful invention does not require finding somebody to blame.[9]
Imagine that a team has promised to demonstrate its robot on a date that is probably too early. The robot drops the ball and everybody begins blaming the programmer. But perhaps the gripper was not adequate, some sensor measurements arrived too late, and nobody wanted to question the deadline. In that situation we could be seeing a mechanism of scapegoating. I am not saying that this has happened in our proposed project. If the program contains a reproducible fault, of course the correct thing is to find it and repair it. That is a technical diagnosis, not scapegoating. We can also say that "the robot is to blame", but the relevant social question is how the people in the team distribute responsibility.
My assessment and conclusion
I think the main strength of this idea is that the objective is easy to understand and the result can be measured. Either the robot retrieves the ball and gives it back to the player, or it does not. The difficulty is that the complete operation depends on several things working together: vision, movement, balance, the grip and the safety system. A successful simulation, or a chip that runs faster on its own, would not demonstrate that the robot can do the job.
There is another objection worth considering. A simpler ball-return device, or a small wheeled machine, might do much of the work with less expense and fewer mechanical problems. The humanoid would have to justify its additional complexity by recovering balls from different positions and returning them reliably to the player. At present this is a proposal to test, not a result that has already been achieved. We do not yet have measured success rates, costs or evidence that a specially manufactured chip would be better.
So I would begin by making the robot do its job and measuring the results. For me, the first success would be a humanoid of 1.69 metres that collects the basketball and returns it to the person shooting from a distance. If a custom chip improves the accuracy, reliability or efficiency of that operation, then it has a reason to exist. If it does not, I would prefer to keep the ordinary electronics. After all, the purpose of the machine is to help us practise basketball, not to oblige us to become chip manufacturers.
Sources
- IC-Link by imec, silicon photonic IC manufacturing: design platforms, wafer fabrication, packaging and testing. ↩ Introduction · ↩ Process
- ASE, silicon photonics and optical packaging: integration with electronics, optical probing and precision assembly. ↩ Back
- Figure, humanoid development and physical design. Background on real robot construction, not evidence of basketball capability. ↩ Back
- Synopsys, FPGA operation and comparison with ASICs. ↩ Back
- AMD, FPGA-based prototyping before ASIC availability. ↩ Back
- Synopsys, physical design and the route to fabrication. ↩ Back
- Tiny Tapeout, small chip design projects and fabrication schedules. ↩ Back
- Internet Encyclopedia of Philosophy, discussion of mimetic desire, models and rivalry. ↩ Back
- The Raven Foundation, explanation of scapegoating in mimetic theory. ↩ Back
Sources consulted on 27 October 2026. The proposed robot architecture, the order of the tests and the example involving a development team are my proposals or hypothetical situations, not descriptions of a robot that has already been built.
Comments
Post a Comment
De genio a geni@, ¿Qué me cuentas?
From genius to genius, what do you tell me?