Some questions.

[modulab]

Hi, I have't got the hardware yet but i'm planing to. I have a few questions for you. Why did you use this MCU? Have you researched other options too? How precise is the positioning at 48Mhz? What is the current speed of the robot? Awesome work !

[solinvictus21]

Edit: Second attempt. My first attempt to respond to your email with an attached video showing the speed of the Zippy moving about on the floor failed because your email server rejected it for size. I'll try to get the video uploaded to YouTube as additional info, but resending the rest of the email without the attachment for now...

Hi! You are the first person to express interest in building a Zippy, so I definitely want to help you in any way I can. To answer your questions in short form, (a) it was just the fastest path to my end goal, (b) lots of them, but I have research many options and am always looking for more, (c) less than half a mm at distances of 1-5 meters from the Lighthouse, and (d) about 600-800mm/sec. The lower speed during turns and the faster on straightaways. I attached a relevant video to show him in motion.

For the longer answers, I've provided more detail below...

(a) I used this MCU strictly because it appeared to be the fastest path to my goal, but I'm open to suggestions for other MCUs. While I was experimenting with the Lighthouse sensor circuit, I actually implemented early versions of the software first on the Arduino Uno and then the Teensy 3.2 platform. Based on your question, I'm guessing you're probably already aware that there are basically two categories of MCUs: 8-bit and 32-bit. And the latter is obviously significantly more capable than the former. I'm a software developer by trade, and I actually didn't realize when I started this project that there was such a big performance gap in the choice of MCUs for robotics projects. I've since begun to favor Cortex-based processors (although ESP32 is an interesting platform as well, mostly for the WiFi integration), and the SAMD21-G18A variant built into the TinyScreen+ was able to provide timings that matched up with the research I've done to understand the timings of the Lighthouse..

(b) I've researched LOTS of other options, but I'm always open to others. Caveat: I'm not a hardware engineer. I've only learned how to solder by hand down to about 50 mils, which limits my ability to design circuit boards using components that I'd otherwise prefer to integrate together into a custom PCB for this project.

(c) I actually have a related codebase that I use to research exactly this question, and all testing I've done is based on that codebase. If you build one (and I'll put together some YouTube assembly videos to help if you do), then you will be able to confirm the same data.

(d) The iPhone app that integrates with the Bluetooth connection will display the information confirming these speeds as well. I'm still tuning the PID controllers, though, so I may be able to get significantly faster speeds in the future as well.

Just let me know if you have any more questions.

Kyle

On Mon, May 14, 2018 at 10:11 AM, modulab notifications@github.com wrote:

Hi, I have't got the hardware yet but i'm planing to. I have a few questions for you. Why did you use this MCU? Have you researched other options too? How precise is the positioning at 48Mhz? What is the current speed of the robot? Awesome work !

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/solinvictus21/Zippies/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/ARGWqn0lKyevC3y-nyv_-vnOy7np1aBNks5tyZCQgaJpZM4T93vY .

[solinvictus21]

YouTube video of one moving around a predefined path on the floor based on positioning info from the Lighthouse.

https://www.youtube.com/edit?o=U&video_id=sSDTUJjHLLc

On Mon, May 14, 2018 at 8:59 PM, Kyle Davis solinvictus21@gmail.com wrote:

Edit: Second attempt. My first attempt to respond to your email with an attached video showing the speed of the Zippy moving about on the floor failed because your email server rejected it for size. I'll try to get the video uploaded to YouTube as additional info, but resending the rest of the email without the attachment for now...

Hi! You are the first person to express interest in building a Zippy, so I definitely want to help you in any way I can. To answer your questions in short form, (a) it was just the fastest path to my end goal, (b) lots of them, but I have research many options and am always looking for more, (c) less than half a mm at distances of 1-5 meters from the Lighthouse, and (d) about 600-800mm/sec. The lower speed during turns and the faster on straightaways. I attached a relevant video to show him in motion.

For the longer answers, I've provided more detail below...

(a) I used this MCU strictly because it appeared to be the fastest path to my goal, but I'm open to suggestions for other MCUs. While I was experimenting with the Lighthouse sensor circuit, I actually implemented early versions of the software first on the Arduino Uno and then the Teensy 3.2 platform. Based on your question, I'm guessing you're probably already aware that there are basically two categories of MCUs: 8-bit and 32-bit. And the latter is obviously significantly more capable than the former. I'm a software developer by trade, and I actually didn't realize when I started this project that there was such a big performance gap in the choice of MCUs for robotics projects. I've since begun to favor Cortex-based processors (although ESP32 is an interesting platform as well, mostly for the WiFi integration), and the SAMD21-G18A variant built into the TinyScreen+ was able to provide timings that matched up with the research I've done to understand the timings of the Lighthouse..

(b) I've researched LOTS of other options, but I'm always open to others. Caveat: I'm not a hardware engineer. I've only learned how to solder by hand down to about 50 mils, which limits my ability to design circuit boards using components that I'd otherwise prefer to integrate together into a custom PCB for this project.

(c) I actually have a related codebase that I use to research exactly this question, and all testing I've done is based on that codebase. If you build one (and I'll put together some YouTube assembly videos to help if you do), then you will be able to confirm the same data.

(d) The iPhone app that integrates with the Bluetooth connection will display the information confirming these speeds as well. I'm still tuning the PID controllers, though, so I may be able to get significantly faster speeds in the future as well.

Just let me know if you have any more questions.

Kyle

On Mon, May 14, 2018 at 10:11 AM, modulab notifications@github.com wrote:

Hi, I have't got the hardware yet but i'm planing to. I have a few questions for you. Why did you use this MCU? Have you researched other options too? How precise is the positioning at 48Mhz? What is the current speed of the robot? Awesome work !

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/solinvictus21/Zippies/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/ARGWqn0lKyevC3y-nyv_-vnOy7np1aBNks5tyZCQgaJpZM4T93vY .

[lgbeno]

Hey Kyle & Modulab,

Cool discussion here, glad to see interest in this area! I can chime in a little bit on MCU selection because I've researched it quite a lot and have implemented the low level lighthouse stuff on a few MCUs (SAMD21 included).

I would say that SAMD21 is a pretty good choice for this application. Mostly because the Arduino support is excellent and that makes adaptation easier for a larger population of people. Most important to the application is availability of a >=24bit or larger timer capture that can be clocked at 48MHz or higher. SAMD21 has this! It is the most difficult processor by far to configure the timer properly but Kyle, looks like you have already gone through that pain.

Other processors that I've used are ST STM32F415 and NXP 54114. The main reason for jumping to a chip like this is to get a faster clock rate and hardware floating point but in the process, you sacrifice the convenience of Arduino.

STM32F415 is quite the beast but also much more costly and physically much larger than the other options.

I think that the Teensy processors are also capable of hardware pulse capture so they are probably the best compromise of a faster ARM processor that also includes Floating point and is very maker friendly.

With that said I think SAMD21 is still an excellent choice with all things considered.

Unfortunately ESP8266 does not seem to have the proper timer capture functionality, some other peripherals can be hacked to serve the function but require constant CPU intervention. I have not researched ESP32 in length but I think that it is very similar in this regard.

With a lot of research, I can say that I have yet to find a Radio System on Chip supporting all of these requirements which is unfortunate.

-Luke

[solinvictus21]

... but Kyle, looks like you have already gone through that pain.

And indeed, it was painful. 🙂 Programming at the AVR layer instead of using the Arduino APIs required reading and understanding a lot of different sections of the SAMD21 datasheet and a LOT of trial-and-error, but it's working great now. Still some optimizations I'd like to eventually add, such as using DMA to collect the pulse edge timings instead of software interrupts, and there seems to be some drift in the DFLL clock in the SAMD21 that I want to figure out how to tighten up. But before I tackle those, I want to make sure that SAMD21 is the platform I'll be sticking with for a while, particularly since ESP32 has caught my eye.

I actually started with Teensy 3.2, and I have quite a bit of the AVR-level code written to capture the Lighthouse edges on that platform as well, but it's not currently checked into the GitHub repository because that codebase on the whole is really quite stale at this point compared to the TinyScreen codebase. It wouldn't take much to move back in the future if I decided to go there again.

I figured the ESP8266 (and ATMega328P in the original Arduino) was probably too under-powered to perform timings at the level that one needs for Lighthouse processing. I actually did some initial experimentation on the original Arduino before discovering this, though when I last looked back at it, I managed to home in on better timings than I would have expected for the processor speed it has available. Still, it eventually became another version of the codebase that has since been abandoned for exactly the reasons you describe.

But as far as the ESP32 platform, I understand that it's actually quite capable and the leap in performance compared to the ESP8266 is comparable to (or even better than) the leap from the ATMega328P to SAMD21 in terms of sheer processing power. I am drawn to it simply for the possibility of replacing the Bluetooth communication I'm currently using on the TinyScreen platform, which is really only for point-to-point. The WiFi capabilities built into the ESP32 platform would allow me to do broadcast communication via UDP packets. Broadcast of some sort is something I will eventually need as I move toward trying to get multiple Zippies to move around in tight coordination together.

If I stick with SAMD21 instead of moving to ESP32, I'll also have to figure out the radio-system-on-a-chip issue (nrf24l01 currently has my eye) as well as how to hand solder down to smaller sizes, since they're all pretty tiny. Sounds like you have some good experience with this stuff, so if you have any insight into how to make soldering tinier components easier, I'm all ears. 🙂

Regards, Kyle

[lgbeno]

Haha, yes, sorry I needed to laugh out loud about the timer stuff because it is almost not documented at all in the datasheet. You probably used some Arduino forum reference code from some very nice people who also helped me read between the lines of those documents!

The DMA work was significantly easier after the fact and I have some ref code for that. I based it off of an ADC example and now that you understand the event system better, this is just an extension of that knowledge.

So I guess full disclosure, I'm working for Triad Semi and we intentionally made these https://www.triadsemi.com/product/ts3633-cm1/ such that customers would not need to deal with fine pitch assembly, at least for our parts. I've also talked with the pcb.ng people a few times, have yet to do a build with them but if you wanted to, we have talked about an arrangement for them to solder on our parts. I have a microscope, reflow oven and do a lot of soldering of these fine components but as of late, I've just been paying to have it done at a place like PCB.ng. It's just too time consuming and tedious vs paying a ~$100 for 6 prototypes that are rock solid.

When talking about raw CPU speed, yes ESP8266 and ESP32 crush most other micros, ESP32 as I understand also has floating point so it is a really good processor and a very affordable price. They are really good for a lot of general purpose applications and the networking capabilities are really brilliant. The things that you lose (as far as I know) are the pulse capture timer hardware so you need to rely strictly on interrupt latencies to get accurate, deterministic time stamps for lighthouse. Some people have been playing with the I2S peripheral that can do essentially logic analyzer style data capture and DMA into memory but then you need the CPU to digest all of that raw data to recover the timestamps. IMO that sort of defeats the purpose of having the fast CPU because it spends its time doing work that is otherwise much more efficiently performed by the timer hardware. An ESP part with proper timer capture (and DMA of timer capture) would be dynamite for this application but AFAIK, it doesn't exist.

So yeah, SAMD21 (or one of the other MCUs I mentioned) and a nrf24 is actually what I settled on using as well. With nrf24, you can certainly do the one to many broadcast that you are wanting, its not UDP but is like UDP in concept. Nrf24 is really a great chip to learn more about this development because it is fairly simple and there is a ton of other people who already dev'ed with it. You are doing low level comms so there is not a Media Access Layer, meaning you might have to put some thought into how many nodes can be coordinated to talk without interfering (crashing) with one another. SMD modules are on ebay for a little over a dollar a piece. I've also used the HopeRF clones which work just fine as well.

Its not out of question to have a SAMD21/20 or SAMD11/10 dong the low level robot and tracking stuff while a ESP32 coordinates its motion paths and network stuff. Just difficult to do all in one chip unfortunately.

[modulab]

Hi Kyle, Luke,

Kyle let me thank you again for the very comprehensive answers. Let me tell you a bit of what we're trying to do. Since i heard of the lighthouse system i wanted to use it in a swarm robot installation (i saw that you also forked the swarmUI repo). My option before this wore limited. i mostly relied on a rfid matrix to locate the robots. So I bought a vive vr and started on the teensy path but this MCU wasn't a favourite because of the relatively high cost for 100+ robotic entities. After some research i narrow it down to three : SAMD21 with esp8266 for wifi, STM32F205 (particle Photon kind of dev board) and ESP32. Currently we are experimenting with ESP32. I have a friend helping me with this, the level of programming required for this task is beyond me, but i find it fascinating. The first major setback was the discovery that the quartz oscillator is limited to 40 MHz even if in the documentation says 80MHz. It's somehow limited by the prescaler (forced at the value of 2). The plan is to grab the timing and shoot it out on a ip port and interpret all on a local server. Nothing more for starter. If the computation can be done remotely i will gladly go in that direction. I've build one half of your circuit with a dual opamp but that didn't work out as planed, I suspect the different value parts i have used. I had some success in capturing the lighthouse signals on the scope with another opamp circuit. But i found this solution to be more expensive than the triad module . So i ordered a bunch of Triad CM1 modules and a SAMD21 dev board and i'm waiting very anxiously for them now. Until then i will keep experimenting with ESP32 and STM32f205 to compare the performance. I will post some updates on hackaday to make it as a log if anybody is interested. Kyle, can you post the youtube link again, this one is redirecting me to my videos?

Luke, thanks for pitching in, very useful info ! And also triad hardware rocks! They gave me a discount on the modules so that was cool.

About the paring of the SAMD21 with a RF like nRF24, i always found those modules very sketchy. I'm suggesting an ESP8266 instead. Anyway, this is my backup plan if i'll find out the ESP32 wont do it. But i trust it will.

Cheers, Paul

[lgbeno]

Paul,

Excited to see what you come up with & we're happy to help!

A module like this https://www.ebay.com/itm/10PCS-Mini-NRF24L01-SMD-1-27MM-wireless-transceiver-module-Small-Size-L/262772325797?epid=898807853&hash=item3d2e737da5:g:iT0AAOSwo4pYWhN0 really isn't sketchy IMO but to each their own. Depends on your comfort level with any given part. Pick what you like and run with it. STM32f205 will work good too.

-Luke

[solinvictus21]

@lgbeno

I needed to laugh out loud about the timer stuff because it is almost not documented at all in the datasheet. You probably used some Arduino forum reference code from some very nice people who also helped me read between the lines of those documents!

It really is poorly documented, as if some hardware engineers were trying to speak the language of software engineers. 🙂 I actually derived quite a bit of that portion of my code from lots of Googling about SAMD21 and PWM capture, which tends to turn up numerous results from the Atmel community forums whose users tend to use Atmel Studio for development, which I can’t use since all my dev machines are Macs. Much digging through those forum posts and the Arduino API source code lead me to the equivalent code that I currently use. Even though I’m using an Arduino Zero-compatible board as my main MCU in the form of the TinyScreen+, I guess I consider myself more of an “generic AVR/MCU software guy” who happens to use the Arduino IDE and notsomuch an “Arduino developer”.

The DMA work was significantly easier…

Right. I figured. DMA is not terribly tricky. I have done some audio work in my dev history, which obviously uses a lot of DMA, and I actually implemented DMA output on the Teensy platform before I switched over to TinyScreen+.

I'm working for Triad Semi and we intentionally made these…

I saw those when they were released. I actually chose to make my own PCB partially to keep the size as small as physically possible but also partially because I wanted an excuse to learn how to design, manufacture, and assemble my own circuits. The op-amp I’m currently using has a pin pitch-width of 50 mils with 0603 passives and, after a lot of soldering practice, I am now able to hand-solder reliably (if slowly and deliberately) at that scale.

I've also talked with the pcb.ng…

Whoa! That’s incredibly interesting and surprisingly cheap. Do they assemble by hand? I’ve actually been reading up about correct package design in Autodesk Eagle to do proper pick-and-place for automated assembly, but I haven’t quite gotten there yet. I’ll definitely do some reading up on pcb.ng. I’d have zero problem paying ~$100 for 6 assembled PCBs. I completely agree that it’s just too much time to spend doing it by hand myself that would be better spent on other parts of my project. I mean, it was fun to learn how it works and how small I could go with it by hand, but I’ve definitely reached my limits compared to the circuit designs and the ICs I’d like to integrate going forward.

And thanks for the info about the limitations of the ESP8266/ESP32 chips to capture pulse edge timings. Based on that info, I’ll definitely just stick with SAMD21 for now, which has no problem capturing pretty-darn-accurate timings. You probably saved me a several-month detour with that info. I kind of didn’t like WiFi as my communication mechanism anyway just because of the power requirements I know it would take. I just figured it’d save me some software pain. 🙂 I’ll just plan to move toward using an nrf24 as soon as I can jump the assembly hurdle.

[solinvictus21]

@modulab

Sorry about the faulty YouTube link. This one should work for you…

https://www.youtube.com/watch?v=sSDTUJjHLLc

I just caught up on your post. You are in exactly the same place I was several months back. I am more than happy to help you out.

First of all, let me start by saying that I’m ultimately developing a “swarm” platform as well. I want to get to the point that I can build several Zippies that can do their own independent path-following while knowing exactly where they are and avoiding each other. To accomplish this, there is definitely a lot more to consider besides just the MCU. Specifically, you’ll need 4 additional pieces of functionality to think about when choosing a platform: battery recharging, wireless communication, motor drivers, and lighthouse sensors. Whichever platform you choose, you will also need to solve those 4 other problems to build out a swarm platform. Please take a couple of pieces of advice from the knowledge I gained from many months of failures I experienced at the beginning of this project.

• Use a 3D printer to make your robot body. This has been endlessly useful in allowing me to iterate on design changes quickly. I can provide recommendations for inexpensive 3D printers if you want them.

• Use metal gear motors, at least while you’re in the initial stages of building out the software. Un-geared DC motors have such a low torque and high RPM that error rates in movement are a nightmare. Plastic gear motors just end up in the garbage every few weeks. The extra space required for metal gear motors is worth the payoff in reliability and movement consistency. I recommend the gear motors I’m currently using for Zippies for a reliable motor that has consistent movement, but whatever motors you choose, stick with something between 500-2000RPM. No faster. You can always move to smaller and/or faster motors later. Of course, stepper motors and continuous servo motors are an option as well, but those are much slower, much larger, and are designed to provide a kind of closed-loop control that you are trying to implement using the Lighthouse instead, so why bother?

If you’re building out your own PCB, which it sounds like you might be doing, I highly recommend the SAMD21. It has a timer clock that you can use that is 48MHz, which is exactly the same as the timer clock in the Lighthouse. Plus it has the ability to capture timings in hardware, which is much more accurate compared to trying to capture timings based on a software interrupt. Timing is crucial when a handful of clock ticks can result in a difference of several centimeters in your estimated position. And if you choose the SAMD21, I will be able to provide better guidance with code samples and such while you’re trying to build the software to calculate position. Regardless of which platform you choose, though, let me know how your project progresses, and I’ll be more than happy to assist with any info that I can, since it sounds like we’re both pursuing a similar path.