Duckiebot debugging

I’ve picked up a Duckietown Duckiebot DB21M. Under the hood it’s a Linux SBC running ROS that talks to the HUT I/O board. There’s a nice host side set of utilities and Docker based tools that let you interact from a standard laptop.

So far I can’t get the motors to spin. I had problems initially with the camera connector being in backwards, which meant the interface ROS node couldn’t start, which dropped all interfaces, but that was found via docker ps and docker logs.

I’m not fond of the nylon fixings. They’re very easy to strip. The supplied SD card seems to be faulty as my laptop doesn’t recognise it, but I had a spare class A1 card that imaged fine. The Duckiebattery is cool - it looks like a standard no-name phone charging battery, but it’s running custom firmware that reports the battery state over USB.

It seems the earlier DB17 used an PCA9685 based HAT from Adafruit, and these were integrated into the Hut?

The firmware is ATMEGA based and seems to have I2C based registers that run the I/O.

Reading the firmware, there is LED 0 (0x40?) Motor 1 (0x60?)

i2cdetect doesn’t detect these devices but it’s skipping addresses.

i2cset -y 1 0x40 0 0x20 gets an ACK.

The LEDs are on command 6 onwards. I can change the colour of the LEDs using i2cset ....

So the HUT processor is working. The register layout is more complicated so I’ll look at the motor supply.

The motor is sold by Sparkfun as a DG01D-E with pinout https://cdn.sparkfun.com/assets/learn_tutorials/1/1/7/6/assembly_encoder_pin_map.jpg which is:

• Motor +
• Motor -
• Encoder VCC
• Encoder A
• Encoder B
• Encoder GND

The next-door servo pins shows 4.7 V, and it’s likely that’s the same supply as the motor driver.

rqt_graph shows a range of nodes including led_emitter_node and right_wheel_encoder_node.

The code shows that you can run commands like rosservice call /ente1/led_emitter_node/set_pattern "pattern_name: {data: CAR_SIGNAL_PRIORITY}"

The flashing is intermittent. dmesg shows that the board is having issues with I2C:

[  498.097932] tegra-i2c 7000c400.i2c: arb lost in communicate to add 0x40
[  498.104813] tegra-i2c 7000c400.i2c: Un-recovered Arb lost
[  500.587954] tegra-i2c 7000c400.i2c: arb lost in communicate to add 0x40

The TOF sensor is working, so it’s not that. Seems to be on address 0x29.

What’s at address 0x70?

The RS datasheet has a parts list at https://docs.rs-online.com/c57a/A700000007343652.pdf. The IMU is a MPU-9250 which is normally address 0x68 or 0x69.

0x70 may be a TCA9548 I2C multiplexer. Does the front bumper board also contain a multiplexer?

Or another PCA9685?

The LEDs seem to stop on a different colour, which is what WS2812 LEDs do when the signal is interrupted. Is the HUT resetting?