New scheme for unique robot ID

[theAgingApprentice]

we're using the ESP32 MAC address to identify the robot chassis, for example to identify soft servo offsets. if we swap ESP32's that falls apart it would be nice to have a real chassis ID, which could be:

• some DIP switches
• a 4 bit rotary switch
• an I2C readable value, maybe something in PCA9685? as we already discussed, using NV RAM in ESP32 for MQTT Broker IP address has similar problems could scan through a list of possible broker IPs, but that doesn't work in new demo environment could use a symbolic name, and look it up in DNS, if DHCP can supply a DNS service pointer might be able to do a MAC level broadcast, that invites Broker to connect and identify itself might also be able to do that at IP layer, maybe more easily

[theAgingApprentice]

We could adopt an idea like this: 1. Put unique serial numbers on each chassis. 2. When the robot looks at the memory for its name and it is not set it could a) use the current MAC address scheme and b) issue a please set my serial number value message to the MQTT broker. If the serial dumber is set then use that instead of the old scheme. 3. We can add an option in the web interface to set the robot name, which could use the serial number in place of the MAC address. To be really ambitious, down the road if we add vision capabilities then the robot could scan its own serial number and set its name for itself. Well worth discussing further I think.

[theAgingApprentice]

After re-reading your comment and mine here is a basic question to resolve. What is the essence of the robot identity?

Your suggestion implies that the PCB (circuit or brain) is the answer. My suggestion implies that the chassis (the body) is the answer. Either way can work. I guess we have to do some robot philosophy to decide which way we want to go. Truly this hobby copies every area of the sciences!

[theAgingApprentice]

To go along the line of thinking that it is the PCB that determines what the robot ID should be tied to, I found this approach suggested in an online forum:

one trick I have heard of, but not used myself, to give a board a unique number is to add a DS18B20 one-wire environment sensor to it. These have a unique 64 bit serial number which can be easily read.

This DS18820 is a temperature sensor that has a unique serial number and a 1 wire protocol. We could not only use this to uniquely identify each circuit, but we could also add temperature reading capabilities to the robot.

If we really want to keep all our options open we could allow for a few different options to exist simultaneously:

1. Serial number on chassis
2. Serial number on PCB
3. Some form of unique circuit ID like toggle switches or a device like the DS18820

We could track all three of these values in NV Ram, note when ent of the values have not yet been set and send reminders via MQTT or whatever, and have any or all ideas available to us to more accurately track inventory. This way any combination of parts could be considered a unique robot.

Lots to think about

[theAgingApprentice]

Placed an order for 4 of these. Expected by Jan 3, 2023. Will be neat to see how to pull the unique serial number from the device.

Order: https://www.amazon.ca/gp/your-account/order-details/ref=ppx_yo_dt_b_order_details_o00?ie=UTF8&orderID=701-8143901-9845816

Data sheet: https://cdn.sparkfun.com/datasheets/Sensors/Temp/DS18B20.pdf

[theAgingApprentice]

the DS18B20 ICs arrived today. There is a Canadian supplier for these called Robojax (a Canadian education and robotics retailer). The IC has 3 pins labelled GND, DQ and VDD. It turns out the VDD may not be needed as the DQ line features parasitic power capabilities. I was trying to figure out what the DQ stands for and here is what chatGPT told me, which I corroborated using Google:

Q: what does DQ stand for on an IC pin? A: DQ is a commonly used abbreviation for "data input/output". It is often used to refer to a pin on an integrated circuit (IC) that is used for data input or output. The specific function of a DQ pin will depend on the IC and how it is being used. In some cases, DQ may be used to refer to a bidirectional data pin that can be used for both input and output, while in other cases it may refer to a dedicated input or output pin.

Q: does DQ stand for Data Quadrature? A: No, DQ does not stand for "data quadrature". "Quadrature" refers to a phase relationship between two signals, and is often used in the context of communications systems to describe signals that are 90 degrees out of phase with each other. DQ, on the other hand, stands for "data input/output". It is a commonly used abbreviation for a pin on an integrated circuit (IC) that is used for data input or output. The specific function of a DQ pin will depend on the IC and how it is being used.

As to the specific purpose of the DQ pin for the DS18B20, the data sheet is here:
https://cdn.sparkfun.com/datasheets/Sensors/Temp/DS18B20.pdf

[theAgingApprentice]

In trying to figure out the labels on this IC I learned that DS = Dallas Semiconductor. Dallas Semiconductor was acquired by Maxim Integrated in 2002 for $2.5 billion. SO the vendor of the DS18D20 can be listed either as Dallas Semiconductor or Maxim Integrated.

[theAgingApprentice]

This appears to be an excellent tutorial on how to use the DS18D20 with Arduino. I will try to follow it to see if I can get the serial number off the device.

[theAgingApprentice]

Wired up the DS18B20 to physical pin 5 of a Huzzah32 dev board. Branched our code and inserted demo code into the set up routine. The code does not detect the device on the 1 wire bus. Note that the sample I am using is for an Arduino UNO board (5 VDC) and the Huzzah we use is 3.3 VDC. I may need to insert a line level converter into the circuit but before I do that I'll look for an ESP32 specific example as I noticed that the libraries used in this example give warnings as well.

[theAgingApprentice]

Found multiple articles stating that using the I/O pins on an ESP32 works fine. These examples all use the same libraries as the original article as well. I did notice a mistake in my wiring and fixed that but the code still does not detect any device on the wire. Will continue to investigate. May need to break out a scope to see what is going on.

[theAgingApprentice]

Tried moving from physical pin 5 to physical pin 10 to match the GPIO number used in the example. Also tried adding a 1 second delay after the setup command for the 1 wire bus but I still have the same issue. This is going to require more investigation. Calling it a day. Will try again later. Still need to discuss with Doug what option we want to pursue for this unique robot name concern he has raised.

[nerdoug]

An updated perspective:

It would be nice to have 3 identifiers for each instance of HFR:

• CPU identifier. We've used MAC address and that seems to work. This determines how external devices communicate with the HFR, and how we create some MQTT names. Might be a combination of MAC address and CPU type: Huzzah, LOLIN32, DEVKIT...

• circuit board identifier. This determines what electronic features are available. May be a combination of board serial number, and revision level.

• chassis identifier. This represents the components that are part of the chassis, and may be a combination of chassis type, chassis serial number, and revision level. Used to select the servo calibration data to be used.

It's important that these identifiers be independent of each other. So the chassis ID needs to be connected to the PCB via a cable / connector, so you can change the PCB without changing either the CPU ID or the Chassis ID.