Autonomous Johnny 5

Lynxmotion Electronics & Software
1

I have a Johnny 5 from Robot Shop/Lyxmotion. It has a Botboardunio and SCC-32. I’ve also got the Ping connected to the Botboarduino. I also added a EasyVR to give voice and hearing and can control J5 by voice. What I really want to do is make J5 autonomous, but I find the amount of memory in the Botboarduino rather limiting. First, I thought add WiFi to J5 and control from my PC. Then I discovered the ESP32 that has both WiFi and 4M of program memory. Light bulb moment why not connect a ESP32 board via serial to Botboarduino. So, I bought a Arducam ESP32 UNO PSRAM from Robot Shop. It has a camera, SD card interface and 4MB program memory. I was thinking it must have some free GPIO pins to provide RX/TX serial interface. If necessary, I will give up the SD card interface. To connect the 3.3v Arducam to the 5v Botboarduino I will use a ‘voltage level convertor’. All sounded straight forward until I tried to find out more about the Arducam’s pin usage – I tried to find out if there are any unused GPIO pins or which GPIO pins are connected to the SD card interface.

Eventually I found this article on how to release GPIO pins and still keep the SD interface functional (if slower):

https://dr-mntn.net/2021/02/using-the-sd-card-in-1-bit-mode-on-the-esp32-cam-from-ai-thinker

This releases GPIO 12,13 which is enough to do serial interface with existing Botboarduino. Now I need to power the ESP32 at 3.3v. This is fine via USB connected to PC, but what I really need is a battery.

I’ve looked on Robot Shop site and there are several promising in-stock LiPo 3.7v batteries, but I need a charger as well. I’ve also read that Lithium batteries don’t like being drained too much!

I am looking for suggestions on combinations that are in-stock and connect together i.e. battery must plug into Arducam ESP32 UNO PSRAM and the charger i.e. it’s a plug/socket thing. Also how do I protect my battery from being discharged too much?

2

@GilbyGrape Welcome to the RobotShop Community!

Very cool project!

I’ve looked on Robot Shop site and there are several promising in-stock LiPo 3.7v batteries, but I need a charger as well. I’ve also read that Lithium batteries don’t like being drained too much!

Aside from the commentary here: Basics: How Do I Choose a Battery? | RobotShop Community

Indeed it sounds like you’ll need a 3.3V regulator, but fortunately they don’t cost much:
https://www.robotshop.com/en/33vdc-regulators.html

The potential issue you might have is the discharge rate of a 6V NiMh battery for all the servos and all of the electronics. If you opt for a second battery (3.7V LiPo as you said), check the datasheet of the 3.3V regulator to know the minimum input voltage (some require at least 3.8V, so although a charged 3.7V battery will be 4.2V, it will drop and produce brownouts).

I am looking for suggestions on combinations that are in-stock and connect together i.e. battery must plug into Arducam ESP32 UNO PSRAM and the charger i.e. it’s a plug/socket thing. Also how do I protect my battery from being discharged too much?

One idea would be to use a 2S LiPo battery connected to two voltage regulators: one down to 6V, the other down to 3V. The servos would not eb fed 7.4V directly.
https://www.robotshop.com/en/60vdc-regulators.html

To save the battery, use a voltage sensor connected to the BotBoarduino and you program it accordingly:
https://www.robotshop.com/en/current-voltage-sensors.html

Just some ideas to get you started.

1 Like
3

Hi cbenson,

Thanks for your reply, lots for me to think about. I will certainly look at ways of monitoring the voltage/charge on the battery.

Regarding 3.3v Arducam board the one thing that is clear from the little information I could find on this board was that a 3.7v lithium battery can be connected to it. I know a 5v USB can be connected and works fine.

I know the Arducam board has the same profile and pinout as the Arduino UNO R3 and am trying to find out if VIN exists on Arducam board like Arduino UNO R3 board. This might be useful since VIN on Arduino UNO R3 can take quite a high voltage (or so I’m led to believe).

I’m not sure what you are talking about when you say “2S LiPo battery”?

My J5 already has 2 6v NiMh batteries to power servos to arms and track motors. I think the track moters can take a much larger voltage, but the body servos need at most 6v. The electronics Botboarduino and SCC-32 are powered by 9v rechargeable batteries and yes they do discharge quite quickly. Maybe lithium for these.

I was thinking that Arducam board would be powered by a 3.7v lithium battery and keep the other batteries the same at first. I’m desparate to program the Arducam board and make J5 aurtonomous, for 35 years I was a software programmer and I love programming.

I’ll update with progress from time to time.

4

I’m not sure what you are talking about when you say “2S LiPo battery”?

A “2S” means a two cell LiPo, so a 7.4V LiPo.

The DC gear motors in the base operate at a nominal 12V (operating them at 6V will likely seem quite underpowered). You can likely get away with using only one 11.1V (3S) LiPo and voltage regulators.

  • 11.1V directly to the motors
  • 6V Voltage regulator split to the BotBoarduino Vin, as well as the SSC-32U
  • Check to see if the Arducam can accept 6V input, and if not, see if the BotBoarduino’s 5V regulator can provide enough current (up to 1.5A total).
1 Like
5

Promised update:

I’ve put the battery and charger issues on-hold, but I like the 2S LiPo batteries with Step Down voltage regulators for the other components. A single 3.7v LiPo for the Sparkfun Thing.

I tried the suggestions on the web for releasing 2 GPIO pins on the Arducam ESP32 UNO PSRAM, but couldn’t get a free pin to work. Gave up. I found the Arducam ESP32 UNO PSRAM works great as a camera with display via an on-chip web server. So it might still be of use on my J5.

Then I got some Sparkfun Thing boards to experiment connecting them to my Botboarduino. Plus a Voltage Level Convertor board of course.

First I tried getting a serial interface to work using Software Serial library on Botboarduino and one of the unused UARTS on the Thing. Plus the voltage level convertor, crossed Rx and Tx. Strangly I couldn’t get this to work, so I tried the I2C interface. This worked great. I then found that I could only send a maximum of 32 bytes from Thing to Botboarduino. I haven’t found a way around this except breaking the message into 32 byte packets and reassembling in the Botboarduino. You appear to be able to send an arbitary number of bytes, but the Thing can only receive 32 bytes in its buffer. Not investigated if this is a limitation of the Thing or I2C, but suspect the Thing.

I also found that the Thing WiFi worked fine with no soldered pins and just the USB to power. Ok the Router was almost next to the Thing. Then I soldered some male pins on component side of Thing and the WiFi stopped working. Finally discovered that if I powered the Thing with 3.3v directly from a Power Supply the WiFi started working and I assume it will also work with a 3.7v LiPo battery, but not tried yet. Still need to try with female headers on component side of Thing which is how it is shown as working.

Anyway some progress :slight_smile:

6

I have Sparkfun ESP32 Thing talking via serial to Botboard, but then noticed Thing Plus says 16MB of program memory.

On Robot Shop web site for Sparkfun ESP32 Thing or Sparkfun ESP32 Thing Plus you use the terms 4MB and 16MB. Is that mega-byte or mega-bit? I have a few Thing boards ESP32 Thing Development Board - RobotShop
and I’m sure it has 4Mbyte so does the Thing Plus have 16Mbyte? I would love 16Mbytes or more😊
SparkFun Thing Plus ESP32 WROOM - RobotShop
The Thing Plus does not mention LiPo charger either while Thing does.

Anyone used a Thing Plus wroom and can answer these questions?

1 Like
7

Can’t say I’ve used it, but indeed, the Plus does seem to have “4MB of Embedded SPI Flash Storage”

The WROOM version:

  • Xtensa® Single-Core 32-bit LX6 Microprocessor (up to 240MHz)
    • 448KB of ROM and 520KB SRAM
    • 16MB of Embedded SPI flash storage
1 Like
8

ESPs are mega Byte, not bits. The internal memory is 4MB and the external PSRAM is also megabyte chips (depending on its size, 8 or 16MB).

Just keep in mind that both the TF/SD card readers and the PSRAM interface to and from the memory chip use some (but not all) of the same hardware pins for the SPI interfaces to and from the hardware. You will want to avoid data collisions with the PSRAM by using the same pins. Since the ESP32 can multiplex its pins, you will want to use the multiplex functions and route your signals to other hardware pins that are not in use by the PSRAM interface.

If you can ensure in software that the TF/SD hardware will not be used concurrently with other data I/O, you can share those hardware pins with other devices. But the best practice would be not to share or multiplex pins that are being used by any other hardware using the SPI buses. ESPs have 2 SPI busses. But for user purposes, SPI Port 0 is the PSRAM bus and should never be used, or data corruption could occur when you write to the bus at the same time the ESP is accessing a memory write on its own. Same goes for the TF/SD bus, (usually Bus 1 for built in readers). The cards can be corrupted in the same manor during I/O processes, unless the developer can ensure no data collisions will occur (device in use flags in software). That leave the final SPI bus, Bus 2 as the only actual usable configurable bus to use safely, without the software multiplexing active.

Regarding the post pertaining to the 32 byte buffers, those are hardware buffers and easily overcome by reading a byte from the buffer and placing it into a self expanding array or into a database queue and process from those, instead of directly from the IO hardware buffer. This can be done using a very small multi task that is triggered to be called at the rising edge of the pin on the Tx and Rx lines. The task then reads the byte or bytes from the buffer and writes it out to the array or database queue, simply moving it off the hardware buffer and keeping it clean and tidy until the application is ready later to actually process the data from the array or database queue. Doing so in this manor prevents IO lockups or packet loss, since some chips will lock up if a buffer is full and more data is seen at the rising edge of the pin to be brought in, and others will simply never bring in the data resulting in data loss if there is no free bytes in the hardware buffer. It all depends on the chips used on the dies when the processors are manufactured.

Using the interrupt event task that is triggered by the rising edge of the pins and moving the data off the buffer into some other object for later management is the best solution and any task then can access said data when its timeslice comes around within the CPU. Interrupts are processed as they occur, and interrupt ongoing processing. That is what you would want in this case. To interrupt and pause ongoing processing, get the data off the hardware buffer and into something that later processes the data once processing resumes.

Hardware buffers for IO are only there to deal with data present when system level instruction can not be interrupted, such as in Atomic Level processing within the processor registers themselves. These system level processes are usually just one or two nano or micro seconds in time. The hardware buffers are usually small (32 bytes is actually a fairly good size one) in order to manage the data as the atomic instructions process, since they can not be interrupted like normal instruction are.

Hope this all helps!

Acigan International
Development Division