When will we have all the spec , docs and soft ??

The more technical aspects of Spirit, and carry-over discussion from Kickstarter updates.
User avatar
Posts: 29
Joined: Wed Sep 13, 2017 5:04 am

Re: When will we have all the spec , docs and soft ??

Postby TomTheWhittler » Thu Jun 28, 2018 1:27 pm

I will have to agree that this project has not turned out as expected. By this time I was hoping to be driving around the little Rover all around my house from work while streaming video. At least the Kickstarter seemed to indicate that possibility which was why I shelled out for a complete unit. I was learning a lot until my Raspberry PI-3 started eating SD cards. After 4 different cards from different vendors I just gave up. Now my Rover is in pieces as it was easier to try SD cards. The Arduino side seems to be just fine if I just want to program simple things. . It all seemed to start when I was having the Pi-3 try to control the Arduino. The Pi-3 seems to work okay just sitting there hardly doing anything but any control stuff that uses a lot of SD card I/O just causes my SD card to self destructs after awhile. A Sandisc 32GB card is now a 20mb card. Another is totally dead. It is a known Pi-3 problem so I can not fault the Rover entirely but I am guessing there still is some code problem helping it along. I'm thinking some sort of Raspberry PI-3 USB to Arduino interface might be better to talk to the Arduino. Not sure. I have learned a lot but I was hoping to learn a lot more and to have more fun.
Research is the only place in a company where you can continually have failures and still keep your job.
I knew immediately that was where I belonged.

Posts: 180
Joined: Tue Jul 28, 2015 12:56 am

Re: When will we have all the spec , docs and soft ??

Postby Kevin » Mon Jul 02, 2018 5:05 pm

Man I'm sorry to hear the Pi is tearing up cards. I don't understand why it would be doing that. All I can think is that it is shutting down and dropping power before the Raspbian OS is finished halting.

You can adjust the time the PIC will wait before pulling power with this function:

Code: Select all

PIC_SetShutdownDelay(sdDelay, sdIntervals);

I would suggest putting this in the setup() function of the Arduino processor so it sends it to the PIC each time it starts up.

Here is the note about this function:

Code: Select all

Set shutdown delay (in milliseconds) PIC will wait when doing
a shutdown sequence. This is the time to allow Pi to safely
shutdown before being powered off. Suggest not to change default,
but you may want to make it longer if your Pi is running a
lot of processes that need time to terminate. Max delay 20 seconds.
sdIntervals is count of 20ms cycles BTN_PWR must be held before
a shutdown sequence is initiated.
Default sdDelay = 5000, Default sdIntervals = 40

I have never heard of the Pi destroying cards just by running the IO lines. I haven't had a card go bad yet but maybe I've been lucky. Unfortunately that would be an issue with the Pi that I can't control. I was let down by the Pi overall. I didn't realize there were so many issues with the hardware pins on that board until we were well into the project. The hardware bug in the I2C port of that chip on the Pi has been a real challenge to work around.

Here is an option I want to consider for getting more reliable comms between the Pi and the PIC. It's a bit of work, but if anyone was willing to spend some time on it, it's not especially hard, and will likely solve all the problems some people are still having with the I2C communication erroring.

Normally the Pi talks straight to the PIC via I2C, and the Arduino also can talk to the PIC via I2C. The comms between the Arduino and the PIC seem to be solid and reliable, it's only when we introduce the Pi talking on that bus that we tend to have problems.

The idea is to send the commands from the Pi through the Arduino. The Pi talks to the Arduino over SPI, which seems to work fine - that is how the demo code is controlling the motors. Servo movement commands (from the Pi) go straight to the PIC via I2C, but the motor commands go to the Arduino via SPI, and that part seems to work really well.

We can pipe the commands to the Arduino via SPI, then the Arduino can send them to the PIC via I2C.

Here is how one would go about doing this:

1) Study the python code on the Pi that controls the motors. It packs up a SPI packet and sends it. This packet is 10 bytes long, plus a checksum byte. That is already in place. It packs up the value "130" as the first byte, which is the key to the Arduino to interpret the packet as motor control. I propose we use a different value, say 140 or something, that would tell the Arduino to relay the data via I2C. We could then make a packet on the Pi that would be 140 at the start, then the rest of the data would be the target I2C register and the arguments that go with it.

2) On the Arduino, on the Pi Slave sketch, we can expand the existing SPI handler (it's toward the bottom of the Comms tab), the function is named "SPI_Handler", and add a new case statement for the new value. Then add a routine to grab the data in the packet and sent it via I2C, which you can see how to do by looking at the other functions in the Comms tab.

3) The above works fine for sending, but getting a query back will be a bit more complex. Maybe you use a different first value like 141 or something if the command needs a reply. I this case, the Pi needs to send a first command, then it needs to wait long enough for the query to take place, then it can run another packet and during the exchange of that second packet, it will receive data back from the Arduino (SPI sends 1 bye out and at the same time receives 1 byte back). On the Arduino side, if it is a query (like a sensor value), the Arduino can run the normal function to do the query, then take the response and pack it up into the SPI_BufferOut array. When the Pi comes back and does the second step, this SPI_BufferOut will be transferred back to the Pi on the next SPI exchange. The Pi can then grab the results from this SPI response.

That really shouldn't take long either. SPI is much faster than I2C, so the two SPI transfers will be fairly fast, you'll just need to wait long enough for the I2C transaction to happen between the Arduino and PIC. I think 1 to 2 milliseconds should be enough for this, but you may need some trial and error here.

It's rare you'd need to poll a sensor faster than this, so it would probably work for most things.

Let me know if any questions on that and I will try to help anyone through it.


User avatar
Posts: 29
Joined: Wed Sep 13, 2017 5:04 am

Re: When will we have all the spec , docs and soft ??

Postby TomTheWhittler » Mon Jul 09, 2018 1:00 am

Apparently RPI-3 killing SD cards is not new or uncommon.
A lot of complaints if you search. Here is just one on the raspberry pi forum.

https://www.raspberrypi.org/forums/view ... p?t=140845

Not sure it is related to the I/O lines.. Maybe it is just my Pi. I got another Pi 3 to try sometime.
I just got extremely busy. Warm weather and rain.. Grass growing.. No time...

And I am not blaming you. How were you to know that the raspberry pi was going to have problems.
There are a ton of projects and shields that seem to work perfectly fine.. I am guessing it
is a weird combination of hardware and some drivers that were not fully developed.

I just thought with 600 Kickstarter backers that there would be a bit more development and enthusiasm from the community.
Research is the only place in a company where you can continually have failures and still keep your job.
I knew immediately that was where I belonged.

User avatar
Posts: 9
Joined: Tue Oct 24, 2017 10:35 pm

Re: When will we have all the spec , docs and soft ??

Postby Astroghost » Thu Nov 08, 2018 4:22 pm

Kevin ,

when will you provide us all the documentations promise on the Kickstarter project ?

Wifi,blutooth and xbee control ?
Computer vision ?

BERNIER François
FabLab Manager at L.A.B. Aix en Provence -FRANCE

Who is online

Users browsing this forum: No registered users and 4 guests