Which pins can't be used when using the Wifi board?

[zlite]

When you're stacking add-on boards, I assume there can be conflict between shared pins. I've looked at the Wifi board schematic and can see which pins are connected, but am not sure how they're used in the software and if those pins are totally out of commission for any other use if that board is attached.

In particular, I want to use the three PWM pins (p7-p9), the ADC pin (p6) and ideally four digital pins (high/low, p2-p4) to set motor direction on H-bridge motor driver. Does using the WIfi board take those pins out of commission?

(apols if there's a pin conflict matrix table somewhere that I've missed)

[kwagyeman]

So, here's the image:

http://cdn.shopify.com/s/files/1/0803/9 ... 1057263430

It looks like more or less all pins are in use. You can't just multiplex these pins without some issues for the wifi.

I'd just send serial data to an arduino to control the motors. Not ideal but it seems you'll have to do that for now.

(The next gen OpenMV Cam will solve this problem - but, until then).

...

Alternatively, instead of using the WiFi shield if you can just use a zigbee or ble module for debug that will only takeup 2 pins.

[zlite]

wifi-pinout.png (847.93 KiB) Viewed 15918 times

Looking more at this, it looks like the WiFi board does nuke most of those other pins. It would be a bummer if it actually does disable two of the three PWMs (P7 and P8) and the ADC (P6) in operation. Am I reading that right?

-c

[zlite]

Got it. That (serial to an Arduino to control motors and servos) was the way I had it before, but I was seduced by the extra PWM pin in the M7 and thought I could now do it all with one board. So be it -- back to Plan A while I wait for the next board. If I have to have a second board, I'd rather have video over Wifi with the official board than just basic text debugging with a serial radio.

(I think this may explain why I was getting funky PWM before with the Wifi board on. Might be worth noting this conflict in the Wifi board listing/notes)

-c

[kwagyeman]

I'll add video support to the firmware in a bit. It's a very easy add. I just haven't done it.

Um, I'll do that tomorrow morning.

Video support over blue/zigbee, etc.

[kwagyeman]

Hi here's a version of the firmware for the M7 camera which has the image streaming feature.

Just do:

print(img.compressed_for_ide(), end='') # works if you are connecting to the camera via usb or VCP to an "Open Terminal" window.

or

uart.write(img.compressed_for_ide())
spi.write(img.compressed_for_ide())
i2c.write(img.compressed_for_ide())

etc.

To send a compressed image. The "Open Terminal" window will automatically decode and display the image.

...

What compressed_for_ide() does is to send the binary data in 6-bit chunks. This makes the data to send larger but maps everything into a safe non-display character area 128-191. This allows for data transport over serial without the possibility of data being confused for printable characters.

If you were to just try to send JPEG compressed data otherwise it would work out horribly. The state machine in OpenMV IDE for parsing the data is robust so images can be but off mid stream and they won't break anything. You should literally be able to connect to a camera streaming image data at any point in time and everything should just work. No syncing required.

...

Finally, run your serial link faster than 1 Megabaud. Images are large...

[zlite]

Sweet! I've got to spin a custom shield for the cam one way or another to do both wifi and robot control. Given what you've now done, which of these two makes more sense?

1) Custom Arduino shield that communicates with the OpenMV via UART 3 and adds a bunch of I/O (downside: need to program the Arduino as well as the OpenMV)
2) Custom WIfi shield based on something like the ESP286 that just uses UART 1 and doesn't block all the other pins like the official shield (downside: can't control web server natively with OpenMV)

-c

[kwagyeman]

I'd use some serial to wireless solution that has a high baud rate. Like, you'll want to drive the uart on the OpenMV Cam at 2-3 megabuad. So, maybe the EPS32 or a bluetooth wireless chip.

Edit:

Upon examination on the market for high speed wireless stuff everything is slow except our wireless shield we already sell...

It looks like the zigbee wifi module using the AT command set is the best serial wifi solution. But, you'd have to spend some effort setting up the wifi module then.

...

Yeah, option 1 basically. I'd just buy a motor controller board you can talk serial to to drive the motors. This way you don't have to write any of that software. Then use the WiFi shield for high speed communication so you can stream images. Using a motor controller board makes sense too given the OpenMV Cam might not be driving the I/O perfectly.

Get a motor controller that talks serial... or i2c if you can't find one that does serial.

[zlite]

Great. Option 1 it is. I'll share the design files later today

[zlite]

Here's the first pass at an Arduino shield (using the Arduino Mini)

https://circuits.io/circuits/4446963-op ... ino-shield

[zlite]

The tricky bit will be how to handle the 3.3v vs 5v issue between the Cam and the Arduino. The Arduino Mini comes in a 3.3v variant, which is probably the way to go, but I'm slightly worried about plugging 5v ESCs/BECs into that servo rail to power the servos. Alternatively, I can use the 5v Arduino Mini, which is very happy with 5v servos, but then I've got 3.3v Arduino serial logic talking to 5v serial logic on the Cam, which is a probably no-no.

On balance, I'm guessing the 3.3v Arduino is the better of the two options. What do you think?

[kwagyeman]

The OpenMV Cam outputs 3.3v and can handle 5v. So, use the 5v Arduino.

[deshipu]

You probably want to power the servos and ESCs from the VIN pin, and not from the 3.3V pin on the OpenMV anyways, and you can have 5V there. I'm doing a similar thing in my hexapod robot for controlling the servos -- I'm using a 3.3V Pro Mini, which I power through the RAW pin with 5V, together with the OpenMV and the servos. The servos don't mind getting 3.3V control signal.

If you try to power the servos from the 3.3V regulator on the OpenMV or the Pro Mini, you are going to burn those regulators -- they can't handle more than maybe 200mA.

[deshipu]

By the way, I'm working on a PCA9685-based servo shield for the OpenMV, maybe that would be more useful?

shot.png (225.95 KiB) Viewed 15890 times

[zlite]

Nice looking board! The reason I'm using an Arduino is that I'm also using the OpenMV Wifi board, which conflicts with almost all the pins but UART3, so I only output serial. Also I need to have some ADCs in for sensor reading. And I only need 2-3 servos.

I'm guessing that your board isn't designed to work alongside the Wifi board?

[deshipu]

My board uses I2C on pins P4 and P5 for communication. Looking at the picture at the top, those pins seem to be free, but I didn't test it yet.

[kwagyeman]

P4/P5 are the UART/I2C pins.

[zlite]

As you suggested, I've tweaked the design to power the PWM rail from the shared VIN/Raw of both OpenMV and the Arduino, rather than VCC, to avoid stressing the power regulators.

[kwagyeman]

I'm confused at the pinout of the shield. It looks like you're connecting to pins used by the SPI bus for data transfer. Please double check the pin layout. http://docs.openmv.io/_images/pinout.png. It looks like you're connecting to UART 1 which is in use by the SPI bus. You want UART 3.

[zlite]

Good catch! Fixed

[kwagyeman]

Um, so is the image flipped? This mounts upside down?

[kwagyeman]

Wait, I think you need to swap the TX and RX pins. The TXO pin of the Arduino is connected to the TX pin of the OpenMV Cam. I think you want the TX pin ont he OpenMV Cam connected to the RXI pin on the Arduino.

[zlite]

Yes, the shield is back-to-back with the OpenMV, so you can get access to the Arduino reset button and the PWM pins. I think I've got the RX and TX pins right. I've labelled the OpenMV pins now so it should be easier to follow:

[deshipu]

I would consider using I2C instead of UART. You have the A4 and A5 pins free on the Arduino, so you can make it into an I2C slave. This way you can connect more things to those two pins.

Here's an example of a Pro Mini-based servo controller that uses I2C for communication: https://hackaday.io/project/9131-servo-controller (click on the 'code repository' to see the Arduino sketch used). I think you could easily modify this to suit your needs.

[zlite]

You're probably right, but I've been traumatized by years of fighting I2C glitches and timing bugs in drones and I've got a bit of PTSD there (we now have a rule to only use SPI for mission critical stuff and we use Serial for everything else). At the end of the day, I always come back to Serial, which always works with every hardware combination I throw at it. It's like English -- not a great language, but ~everyone can speak it.

To be clear, I2C is very good for driving motors and servos. But I need this module to read sensors, too, and we've had trouble with I2C timing glitches introducing sampling biases in sensors. That's why we won't use it for any mission critical sensing.

[deshipu]

I suppose you could use the same SPI bus as the wifi shield uses, and use one of the free pins as CS...

[zlite]

Here's the real thing. So far so good!

[zlite]

Slight update. I decided to move the Serial Rx and Tx pins on the Arduino that talk to the OpenMV to SoftwareSerial on Pins 2 and 3, so you can still use the hardware serial Rx and Tx pins for the FTDI cable to program it and monitor serial output while it's attached to OpenMV:

[deshipu]

Shame you didn't move them to A4 and A5, then you would have the option for I²C

[zlite]

BTW, I tried both 3.3v and 5v Ardiuno Minis and they both worked fine (I guess the logic lines are tolerant of both). So might as well go with the 5v and get the faster clock speed

[Drews]

Shame you didn't move them to A4 and A5, then you would have option for I²C

Good idea, I'm going to give that a try on my project.