Mark Booth

I think you're a great set of mods to take the site forward, and know that when the site grows enough to need a 4th mod, I'll be there, offering to step forward again.

@Chuck I'm not going anywhere, plus I now have a chance to get some of those badges that are really difficult to get when you have a diamond. *8')

Thanks to both @Chuck and @Tully for throwing your hats in the ring. It's great that we get to have a proper graduation election, even if it does mean I might lose my diamond. *8')

Congratulations to Chuck, Ben and Tully, our newly elected moderators.

Thanks for the reminder @Chuck, I was just a little busy and didn't want to put in a half-hearted application. All done in plenty of time though.

Thanks @Chuck that's a good call.

Not heard anything more, I believe it's in the hands on the CM team now.

@Chuck Please let me know if you still need me to contact you, it looks likely that the issue you wanted to talk about is already being dealt with by the mod team and community moderators, so it's looking hopeful that it might go ahead, if the logistical issues can be resolved.

Aw, thanks for the translation @NickAlexeev *8')

@NickAlexeev Any changce of a translation of the speech bubbles? I'd give it a go with google translate, but I've no idea hot to type cyrillic script intro it. *8')

Happy arbitrary position on our planets orbit to all. *8')

If the electricity for your data centre comes from a coal or gas fired power station that's probably true, but then you should be decarboinising your grid anyway. If you provision as much renewable energy generation as your data centre uses, it won't be a problem. I would much rather energy were going into AI model training than mining bitcoin.

I think that continuous retuning like that would be very difficult to get right @TannerSwett, I've always considered tuning more of an art than a science, and capturing all of those judement calls in code would be fiendishly difficult.

That may be interesting @ManuelRodriguez but it wasn't really what @AkshayKumar was asking about. Telling someone 'you don't need to detect faults as future hypothetical robotic systems will correct faults for themselves' doesn't really help them.

Erm? Where did I suggest that? No, a system with new motors, bearings, electronics, mechanics etc will work as well as you program it. Over time, motors wear, requiring more current for the same toque, bearings degrade, requiring more torque for the same move, electronic components age, and even mechanical components rust, bend or fatigue. All of these things need to be monitored, either through a comprehensive maintenance schedule and system downtime, automated detection or often both.

As systems age, their response characteristics change. A robot which works perfectly one day can fail the next day as mechanisms wear and drift out of tolerance. Systems which identify and report on failing components are essential in high availability requirement environments (such as industrial just in time manufacturing), so I wouldn't be so dismissive @ManuelRodriguez

In theory the difference between theory and practice is negligible, in practice, it's less so.

Spot on @Chuck and I hope you get something interesting working @somers

That's completely understandable @N.Staub, any help the community can provide is always appreciated, but no-one expects anyone to spend their time helping out. Often, a close vote or a flag is enough to bring a problem question to the attention of someone who hopefully does have the time to deal with it appropriately. My problem is always find the problem questions, rather than working out how to deal with them.

We just have to be patient @N.Staub, I try to strike a balance between encouraging people to try again, and helping them understand what we expect.

HI @RobinW, although asking a question for sources like this wouldn't be appropriate on Robotics, describing your current approach and what problems you are having, and asking how you can solve those problems, would be a good question. You may well get pointed to goos sources as part of that, but you may also get your question answered directly too.

Did you delete and re-ask @Paul?

My gut feeling @Sam is that at that bit rate, you are likely to have problems with jerky movement unless you can somehow stream commands so that new position/velocity demands are queued up before previous demands have completed, and those demands smoothly follow on from the previous demands.

Either way, I would expect updates once a second to result in quite jerky movements, unless the robot is moving quite slowly.

It's difficult to tell Sam, are you calculating your own kinematics, i.e sending raw motor/joint positions, or are you sending positions in your desired coordinate frame and letting the robot do it's own kinemetics?

I used to work with Aerotech A3200 soft controllers's these provided 32 axes of synchronised motion control, with the motor amplifier rack connected to an Industrial Pentium 4 PC via firewire. DAC demands were sent down the firewire, encoder counts were sent back. Real time executive software partitioned off one whole core of the Pentium 4 just for the user of the servo controller software, leaving the other core for running windows.

Also, it depends on the serial bus. 110kbps RS232 is rather different to 400Mbit/s firewire, and both are serial.

If the motors are doing all of their own position and velocity control, and serial is just used to send new waypoints.

That depends @Sam

That's why finding duplicates is such an important part of keeping the site clean. A question is not a duplicate because it is asking about an identical problem, it is a duplicate if the same answer or answers provide a solution for the problem.

That's why I often suggest people try to break down complex problems into a series of more tractable specific questions. It doesn't work often , but I've found working out how to ask the right questions sometimes gives you the levers you need to answer those questions anyway.

At least over on Stack Exchange it's relatively easy to reframe a coding problem not to give too much away, here omitting such information would be far more likely to make a question unanswerable.

Robotics Stack Exchange has always been a hard sell for engineers and industrial roboticists, Robotics didn't exist when I was working in the industry, but even if it had existed, I'm not sure how many questions I could have brought here without breaking the commercial confidentiality of our customers.

Thanks for the heads up @N.Staub

I've alerted the user of the Stack Exchange rules on self promotion.

I would also recommend looking at what Deiberate Practice means. For an excellent summary, see Jon's 2 page chapter in "97 Things Every Programmer Should Know" p44: programmer.97things.oreilly.com/wiki/index.php/…

Then practice developing solutions for more complex problems, making sure that you don't fall back into old "develop up front" practices.

Pick a language you are most comfortable with, pick an easy exercise, and just develop the solution in a TDD way. Once you're done, check that you see the red/green/refactor cycles in the traffic lights on the summary page.

To be honest @holmeski the easiest way to learn TDD is to do it. I would highly recommend having a play with Jon Jagger's cyberdojo, designed for doing Deliberate Practice: cyber-dojo.org

Congratulations @somers don't forget about when your mechatronics career takes off. *8')

I would suggest that you copy your original message to the new chatroom and then delete the old one so people don't get confused.

There absolutely are techniques which can formally prove that software is bug-free with respect to it's specification. This is not the same as bug free with respect to what's actually required. The main reason why Z notation (probably worth mentioning in that 2nd paragraph) didn't take off, is that it just pushes the bugs from the code layer up to the specification layer, and coders tend to be much better at coding to a specification than non coders are at specifying what they want anyway, a large part of our jobs is extracting those specifications.

@guthik Happy to help.

Chuck is right, this room will eventually be frozen, but since it is a conversation of more than 15 messages between at least two users, it should always be accessible via the transcript link: chat.stackexchange.com/transcript/123623 if you would care to bookmark that.

It's great to see 3dprinting doing well by the way. I was always disappointed that we didn't get Digital Farbrication out of closed beta.

That's what I love about stack exchange @0scar it doesn't matter how much of an expert you are, there are always things to learn.

The transputer lasted in the embedded sphere far longer than most people realise. STMicroelectronics's ST20 cores formed the heart of many set top boxes way into the 21st century, and some Inmos people went on to form Xmos, still in Bristol, where some transputer techniques were reborn in a signal processing context (most recently far field voice capture, e.g. for Alexa like devices).

Payment a month in arrears I would expect in the U.K., having a weeks deduction in addition to a month in arrears I would not expect.

For months afterwards, every time a file was touched, the auto reformatting was done and all of the functional changed were mixed in with the format changes, so any time we needed to merge in changes from a pre-auto formatting branch to a branch containing auto-formatted files, we had a huge number of conflicts to resolve.

The trouble @eckes is that you really need to do a one hit reformat of everything when you implement auto formatting. The mistake we made was to turn on auto-formatting without doing a global reformat.