Discussion on the Standard of remote Control Protocol about esp32camerarover2 HOT 6 OPEN

Are you trying to compile this project?
I compiled it successfully, but unfortunately, when the phone is connected to AP, esp32 will restart.
I don't know what the problem is. It would be great if you could help me.
Looking forward to your reply!

from esp32camerarover2.

esp32 restart generally means it is not getting enough power. The esp32cam pull a lot of power when it first starts. Also, any issues with common ground between motors and esp32 (and the serial adapter for programming) can cause a reboot. I would try these;

• Reboots may happen if you have the serial programmer connected when you reboot; I always disconnect it before restarting the esp32cam.
• disconnect power from motors (don't send power to L9110S) and try booting; if it boots then it's possible you don't have enough power for both the motors and ESP32. Note that in my setup, once and while when I boot after programming the esp32 the app will not start correctly; if I then just reboot using the reset button it will start; I suspect cold-boot draws too much current as both the esp32 and motor driver are starting from off. So when I reset, both esp32 and motor driver are already powered up and so there is not as much of a current draw so it succeeds.
• The application is not designed for more than one client to connect at one time. So if you have a phone and a desktop web browser connected, it may cause the app to crash. That being said, I have definitely connected using the web browser on my phone and successfully drove the rover.
• I power the Esp32Cam via that 5v pin. I've read that powering via the 3v3 pin may cause some issues because it is not going though a voltage regulator, so if the power is a little noisy then the esp32 will see that. Going through the 5v pin means that the power will go through a voltage regulator to bring it down to 3.3v, which has the benefit of smoothing out noise in the input.

Can you tell me now you have your rover powered? Can you send a photo? Thanks.

from esp32camerarover2.

As for the protocol between the rover and the web client I agree we could improve this. I wanted a text protocol so it is easy to debug. Also, I wanted to be able to acknowledge receipt of a command. The protocol has two features that work together for this purpose; 1) each command is given an id from a monotonically incrementing id, which also allows commands to be ordered on the other end, 2) command receipt is acknowledged by reflecting the received command back to the client, but in an 'ack' package.

I'm happy to look at improving the protocol by implementing something more standard. I'll take a look at what you linked.

from esp32camerarover2.

I did a little research on that link you provided. That project is using the IBUS serial protocol to talk between an Arduino and an RC receiver. The IBUS protocol seems to be dedicated to this application; you send send/receive servo values and sensor values. It is not a general serial protocol that would support our application. For instance, there is no way to send a 'goto' command to the rover using that protocol.

from esp32camerarover2.

The gopigo robot uses an custom HAT that includes a microcontroller. It interfaces to the host RaspberryPi using the I2C bus and a binary protocol. See gopig github This has a lot of functions going on in it.

Openbot uses an Arduino for low level control of motors, LEDs and for reading encoders. It uses serial (via USB) to talke to an Android phone. Here is the OpenBot firmware. It's very low level and does not actually do speed control or pose estimation.

I like an ascii human readable protocol because you can test the robot via the serial port without the need for a controlling computer. It also makes debug output easy and obvious. So what we have so far is pretty good; we should look at abstracting how commands are sent and responses and telemetry received so we can make the bot work with serial port (and so make the code run on an OpenBot) or via I2C (so it we can make it run on a Gopigo)

from esp32camerarover2.

I think we can do better by:

• message number: I was calling this command id or command number. This is the monotonically increasing id produced by the sender of the message. It provides uniqueness and ordering. So the rover itself will generate a new message number for each message it sends through the web socket to the web UI. The web ui will generate a new message number for each command/message it sends to the rover via the web socket. The message number is unique for a given web socket. If a client has more than one websocket it does not need to try to keep the message number's unique across all websockets; however when acknowledging a message it must send the acknowledgment on the same web socket that it received it on so that the original message id makes sense to the receiver of the acknowledgment.

1. Make sure each message is 100% json, so rather than set({"left":{"forward":true,"pwm":217}}) it would be {"set":{"left":{"forward":true,"pwm":217}}}. That makes it much easier to parse a command and dispatch it.
2. move towards using schemas to reduce the size of packets, so {"forward":true,"pwm":217} would have a schema that defines the field names, their types and their ordering so that we could send [true,217] and still reliable validate and decode it. It remains valid json, but it requires the schema to re-hydrate it to {"forward":true,"pwm":217}. So effectively a struct format for the data. So the full command message might be ["set", ["left", [true,217]]] if it was fully schema'd. Or possibly even ["set","left",true,217] to set a single value or ["set",[["left",true,217],["right",true,195]] if the command allows for multiple values to be set with a single command. We could reduce this further if we assigned numerical enum values for "set" and "left". Further we could use 0 and 1 for boolean values rather than false and true. That being said, using strings does make this easier to read for a person and does not give up that much in space relative to a 32bit number.
3. We still want a container that includes the monotonically increasing message number and the checksum/CRC and we would like that to also be json, so something like [12345, ["set", ["left", [true,217]]], 3254] where the first number is the monotonically increasing message number, the second field is the command and its arguments and the third field is the checksum, which is the command number plus checksum of the command computed from the command rendered as a string. So if the message was actually an empty string (so it' checksum is zero) then the checksum would equal the message number.
4. Acknowledgements can be very short, [13427, ["ack", 12345], 213], where first field is the response message number, second field is "ack" and third field is CRC of "ack" plus the command number.

from esp32camerarover2.