Do robotic arms in a car plant operate mostly based on information provided by sensors? Like they aren`t thought to operate blindly, there is a process of camera/sensor based aiming/homing (if we talk about say a welding arm) on the region where work needs to be done.
It's the entire range between no sensing at all to switches to detect objects to vision systems to detect objects and positions of them, and everything in-between. There is no one sensing system to rule them all.
One of the reasons why I`m asking is I remember seeing car plant footages from the 80`s displaying robotic arms working unassisted (by man) on car frames. Back in those days the sensor technologies were pretty much inexistent so lot`s of questions raising with regards to that kind of footage.
From what you`re saying I get that initially it was 'touching' based.
Those robots were programmed to repeat a fixed set of actions with very little sensor intervention. Move forward x inches, move left y inches, spot weld for z milliseconds, move back, and wait for the next car to arrive.
How does the music data get stored on a CD? What I mean is you can switch between music CD tracks with the next or previous track buttons. How does the reading head know where to jump on the spiral location where the next track begins? Is there a track directory listing containing the track start position for every track on the CD?
Are microcontrollers in a way universal, in theory any program can fit into a microcontroller which means that the same microcontroller can fit the needs of any printed circuit board (since the program on the microcontroller can be adapted to meet the needs of any circuit board)?
I also have a question about car electronics. The car has various parameters, most of then need just to be displayed to the driver (vehicle speed, engine RPM, etc.) and it`s up to the driver to decide the amount & moment when change should be applied to those parameters. If the parameter display is digital I assume some kind of microcontroller is required to transform sensor data into humanly readable onscreen information. But my guess is that there are also parameters that are altered/changed after being read without driver intervention. In this later case the change comes from a microcontroller with a program designed to cause change. So basically a microcontroller can be used to either aid the display of information about various car components or actually change, at it`s own discretion, how those car components operate.
Are my assumptions close to how things are working in practice.
I think you can assume that any microcontroller is Turing complete. So in theory, any microcontroller can replace even the most huge supercomputers. And every computer of any intermediate rank.
But then again: In theory, there is no difference between theory and practice, but in practice there may be.
Microcontrollers tend to have a very short paper tape. Clock speeds may be measured in kHz; memory sizes in kilobytes. (Well, there are as well microcontrollers running at quite a few MHz and addressing gigabytes, but some of them could deserve being called millicontrollers ...).
Microcontrollers are plain CPUs, but often packed with a lot of I/O circuitry on the chip, and some RAM / ROM / Flash - maybe all that the CPU needs in typical applications. Frequently, all that is needed is integrated on the chip, and it may be referred to as a SoC - "System on Chip".
For the car: Anything that can be read as a digital signal can be read by a microcontroller. Many microcontrollers also have one or more analog-to-digital (A/D) converters on-chip, so the signal need not even be digital outside the chip (but the handling of the reading is always done after it has been digitized). Anything that can be controlled through a digital signal can be controlled - call it 'changed', if you prefer - by a microcontroller. Likewise, microcontrollers may have on-chip digital-to-analog (D/A) converters, for (car or other) components that require an analog control signal. In a modern car, lots of components are not manipulated directly by the driver. The driver sends a signal to a controller requesting it to take the necessary steps to obtain some desired result, whether to start the engine, operate the ABS breaking system, or flash the blinkers.
This goes for almost all modern electronics: Today you hardly ever turn a potentiometer or press a switch to make a current flow. You still have dials, but they only serve as signal generators for a processor (/microcontroller) that in turn sends the "real" control signal to the component, possibly after some checking, adjustments, or reshaping.
Most likely, the rich set of I/O facilities typically integrated into the microcontroller makes it far better suited to such control tasks (guess what has inspired its name!) than, say, the typical CPUs found in desktop computers. A microcontroller usually runs a fixed set of software functions, and perform a fixed set of tasks - you boot it up with the software it will need, and do not add any more later. Knowing the tasks it will run, you will know how powerful it has to be, and you select a microcontroller accordingly. For battery driven applications you may also select clock frequency accordingly - the lower the frequency, the longer the battery life.
Sorry, I cannot offer any suggestions beyond what is in that link. But I am a little concerned as to all those different devices in use on your system. Maybe it's time for a complete reinstall from clean.
Sorry, I have use ubuntu in multi-boot situations a number of times and have never encountered anything like the situation you are showing. I can only suggest you find a specialist Linux support website where you may find someone with a deeper knowledge.
That's easy enough to test. Turn on a bluetooth device. Do not pair or connect, and run a scan. I think you'll find that the scan reports the device presence.
My expectations are:
scan - find any nearby device with bluetooth receiver turned on - may or may not report devices that are paired to other servers and not soliciting for connection
pair - establish a connection to a scanned device that is soliciting for a connection
connected - a pairing has been established and the server can communicate with the device.
How safe or dangerous would it be to stop and restart the
Linux Bluetooth service itself ?
It should not affect the running of the Linux system at all. It might leave any connected bluetooth devices "orphaned", I.E. with a connection that the kernel doesn't know about, but I really do not know. You almost certainly can't damage the linux system beyond needing a reboot to get back to where you were, so if I were you I'd try it and see what effect it has. In particular I'd look to see if currently connected devices keep working, and if the stuck process recovers quickly after the restart. I suspect that restarting the service won't affect the stuck hcitool process. It probably has all it needs to do its work, so restarting the bluetooth service won't affect it. You should probably take a look at what hcitool is doing when its stuck - it may be a bug in the process, which you could report to the developer, or it may be due to some bluetooth device not properly implementing the discovery protocols, which leads to problems, or, well, anything!
A "stack" is the set of programs and/or system services needed to supply a given end-user (in this case) service.
As I understand it, for bluez there's
User programs : e.g. hcitool
System software : e.g. whatever system processes are needed to monitor/provide bluetooth services
System libraries : e.g. libbluetooth this provides interfaces for both system and user programs
Kernel module : e.g. bluetooth module, which provides the kernel side implementation details
As you can see, this forms a "stack", with each layer needing services from the layer below it to provide the services it needs to the layer above.
Keep Calm and Carry On
Last Visit: 31-Dec-99 18:00 Last Update: 23-Sep-23 20:24